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I .  INTRODUCTION 


An  expanding  field  of  interest  in  computer  science  is 
that  of  software  engineering.  It  is  important  to  the 
development  of  software  systems  that  critical  work  be  done 
early  in  the  design  of  software  systems.  Therefore  the 
development  of  a  functional  specification  is  of  great 
importance  to  the  design  effort.  Berzins  [Ref.  1] 
developed  a  formal  language  SPEC  for  writing  black-box 
specifications  for  components  of  software  systems  in  the 
functional  specification  stage  of  software  development.  To 
increase  the  readability  of  this  code  a  software  tool  was 
designed  to  format  SPEC.  This  thesis  centers  on  the  design 
and  implementation  of  a  language  dependent  pretty  printer 
for  the  SPEC  language. 

A.  OBJECTIVES 

The  main  objective  of  this  thesis  is  to  design  and 
implement  a  language  dependent  pretty  printer  to  format 
SPEC.  Appendix  A  [Ref.  2]  contains  a  listing  of  the  grammar 
for  SPEC  language.  The  code  for  the  pretty  printer  is 
written  as  an  attribute  grammar.  This  code  is  then  compiled 
using  Kodiyak.  The  output  of  the  Kodiyak  compiler  is  the 
executable  code  for  the  pretty  printer  to  format  SPEC. 
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Additionally,  it  is  desired  that  the  pretty  printer 
code  be  easy  to  read  and  change.  Since  this  is  a  research 
project  code  efficiency  is  not  as  important  as  code 
readability.  It  is  essential  that  the  pretty  printer  code 
operate  correctly  and  that  other  researchers  can  understand 
and  modify  the  code. 

The  final  objective  is  to  try  and  take  what  is  learned 
in  this  implementation,  abstract  it,  and  develop  guidelines 
for  a  language  independent  pretty  printer  using  Kodiyak  and 
attribute  grammars.  These  general  guidelines  are  a  direct 
result  of  the  insight  gained  from  the  design  and 
implementation  of  one  pretty  printer  using  Kodiyak  and 
attribute  grammar. 

B .  RESEARCH  QUESTIONS 

There  are  two  research  questions  for  this  thesis. 
First,  what  are  the  underlying  issues  and  decisions  that 
must  be  made  in  the  design  and  implementation  of  a  language 
dependent  pretty  printer?  Once  these  issues  are  identified 
what  is  their  impact  on  readability,  ease  in  modifying, 
portability  and  efficiency? 

Second,  can  a  language  independent  pretty  printer  be 
developed  from  the  methodology  used  in  this  thesis  in  the 
development  of  the  language  dependent  pretty  printer?  Is 
the  implementation  regular  enough  to  abstract  general  rules 
and  guidelines  or  is  the  implementation  based  on  many 
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special  cases  and  no  general  rules  and  guidelines  are 
possible? 

C.  SUMMARY  OP  FINDINGS 

The  final  output  from  the  research  conducted  in  this 
thesis  is  the  implementation  of  a  working  language  dependent 
pretty  printer.  Though  it  may  not  be  optimally  efficient  it 
works  correctly  and  the  code  is  readable.  Appendix  B 
contains  the  pretty  printer  code  listing  and  Appendix  C 
[Ref.  3]  contains  sample  input  and  output  for  the  pretty 
printer . 

Additionally,  from  the  work  done  in  the  development  of 
the  pretty  printer  a  set  of  general  guidelines  is  developed 
for  the  design  of  a  language  independent  pretty  printer 
generator.  This  generator  will  need  a  preprocessor.  Output 
of  the  preprocessor  is  transmitted  to  the  Kodiyak  compiler 
with  the  output  from  the  compiler  an  executable  code  for  the 
pretty  printing  of  the  language  defined  by  the  input  to  the 
preprocessor . 

D.  ORGANIZATION  OF  STUDY 

Chapter  II  lays  the  theoretical  framework  for  the 
design  and  implementation  of  the  pretty  printer.  The 
details  of  attribute  grammars,  Kodiyak,  pretty  printers  and 
SPEC  are  discussed.  These  four  areas  are  heavily  used  in 
Chapter  III  and  Chapter  IV.  Readers  unfamiliar  with  these 
subjects  will  find  this  chapter  necessary. 
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Chapter  III  explains  the  design  questions  and  design 
decisions  that  are  made  in  this  implementation. 
Additionally  an  explanation  of  the  attributes  used  to  create 
the  pretty  printer  are  outlined.  The  final  subject  in  this 
chapter  is  the  general  and  specific  rules  for  the  pretty 
printer.  A  user  of  the  pretty  printer  code  needs  only  a 
working  knowledge  of  the  general  rules.  A  person  who  is 
going  to  modify  the  pretty  printer  or  wants  more  details 
will  find  the  specific  rules  define  the  operation  of  the 
pretty  printer. 

Chapter  IV  covers  the  conclusions  of  this  thesis.  The 
conclusions  address  the  issues  of  the  specific 
implementation  and  how  this  implementation  can  be  extended 
to  generate  a  language  independent  pretty  printer  generator. 
The  lessons  learned  in  the  design  of  the  language  dependent 
pretty  printer  are  abstracted  to  produce  guidelines  for  the 
future  development  of  a  language  independent  pretty  printer 
generator  using  Kodiyak  and  attribute  grammar. 


4 


II.  BACKGROUND  THEORY 

This  chapter  lays  the  theoretical  framework  for  the 
design  and  implementation  of  the  pretty  printer.  In  this 
chapter  details  of  the  following  four  subject  areas  will  be 
discussed : 

(1)  Attribute  grammars 

(2)  Kodiyak 

(3)  Pretty  printer 

( 4 )  SPEC 

Chapter  III  and  Chapter  IV  of  this  thesis  draw  heavily 
on  developments  in  these  four  areas.  Readers  unfamiliar 
with  these  subjects  will  find  this  chapter  necessary. 

A.  ATTRIBUTE  GRAMMARS 

A  grammar  consists  of  a  finite  set  of  nonterminal 
symbols,  a  finite  set  of  terminal  symbols,  a  set  of 
production  rules  and  a  start  symbol.  A  language  defined  by 
a  grammar  is  a  set  of  strings  consisting  only  of  terminal 
symbols  that  can  be  generated  by  the  grammar.  [Ref.  4:p.  81] 
A  nonterminal  symbol  is  defined  as  a  variable  or  a  syntactic 
category  [Ref.  5:p.  77].  A  terminal  symbol  is  defined  as  a 
symbol  that  can  appear  only  on  the  right-hand  side  of  a 
production  rule  [Ref.  6:p.  97]  or  as  a  primitive  symbol  of 
the  language  [Ref.  5:p.77]. 
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An  attribute  grammar  is  an  extension  of  a  context-free 
grammar  whose  generated  language  includes  syntax  and 
semantics.  A  context-free  grammar  (CFG)  is  a  four  tuple  G  = 
(N,T,P,S)  where  N  is  the  set  of  nonterminals,  T  is  the  set 
of  terminals,*  P  is  the  set  of  production  rules  and  S  is  the 
start  symbol  [Ref.  4:pp.  84-85].  The  syntactic  part  of  the 
attribute  grammar  is  typically  a  context-free  grammar  and 
the  semantic  part  consists  of  a  set  of  attributes 
associated  with  each  symbol  and  a  set  of  semantic  functions 
used  to  evaluate  the  attributes'  values  in  term  of  the 
syntactic  tree  [Ref.  7:p.  331]. 

The  attributes  provide  a  means  for  expressing  data  flow 
in  the  derivation  tree.  They  are  associated  with  the  node 
in  the  derivation  tree  and  represent  inputs  and  outputs  of 
the  nodes.  The  attributes  of  each  node  in  the  tree  can  be 
defined  in  terms  of  the  attributes  of  neighboring  nodes. 

An  important  feature  of  an  attribute  grammar  is  that 
some  of  the  attributes  are  defined  for  nonterminals  that 
appear  on  the  right  side  of  the  corresponding  production 
rule,  while  other  attributes  are  defined  when  the 
nonterminal  appears  on  the  left  side  of  the  corresponding 
production  rule.  This  implies  there  are  two  types  of 
attributes.  First,  a  synthesized  attribute  is  based  on  the 
attributes  of  the  descendants  of  the  nonterminal  symbol. 
Second,  an  inherited  attribute  is  based  on  the  attributes  of 
the  ancestors.  Synthesized  attributes  are  always  evaluated 
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from  the  bottom  up  in  the  tree  structure,  while  inherited 
attributes  are  always  evaluated  from  the  top  down  in  the 
tree  structure.  [Ref.  8:p.  130] 

Figure  2.1,  from  Knuth,  shows  an  example  of  an 
attribute  grammar  which  gives  a  precise  definition  of  binary 
notation  for  numbers.  This  binary  notation  is  based  on  the 
definition  of  the  context-free  grammar  (as  listed  in  the 
left  column  of  Figure  2.1).  The  terminal  symbols  are 
"0"  and  "l".  The  nonterminal  symbols  are  "B",  "L"  and  "N" 
representing  respectively  bit,  list  of  bits  and  number.  A 
binary  number  is  intended  to  be  any  string  of  terminal 
symbols  which  can  be  obtained  from  "N"  by  application  of  the 
production  rules  listed  in  the  context-free  grammar.  [Ref. 
8 :pp.  127-130] 


Semantic  Rules 

v  ( B )  =  0 
v ( B )  =  2**s ( B ) 

V { L )  =  v(B) ,  S ( B )  =  S ( L ) ,  1 ( L  )  =  1 
v  (  LI )  =■  v  ( L2  )  +  v  (  B  )  ,  s  (B  )  =  s  ( LI  ) 
S(L2)  =  S(L1)  +  1,  1 ( LI )  =  1 ( L2 )  +  1 
v ( N )  =  v(L) ,  s ( L )  =0 
v ( N )  =  v ( LI )  +  v ( L2 ) ,  s ( LI )  =  0, 
S(L2)  -  -1 ( L2 ) 

Note:  "**"  symbolizes  exponent 

LI,  L2  are  subscripted 

Figure  2.1  Binary  Notation  Example 


!  Syntactic  Rules 

B  ->  0 
B  ->  1 
j  L  -  >  B 
LI  L2B 

N  ->  L 

i  n  ->  LI  .  L2 
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The  right-hand  column  of  Figure  2.1  represents  the 


semantic  rules.  The  semantic  rules  define  all  the 
attributes  of  a  nonterminal  in  terms  of  the  attributes  of 
its  immediate  descendants.  Values  are  ultimately  assigned 
for  each  attribute.  The  three  attributes  used  in  this 
example  are  "v"  for  value,  "l"  for  length  and  "s"  for 
scale.  Figure  2.2  gives  an  example  of  the  association 
between  attributes  and  nonterminals.  Figure  2.3  lists  the 
synthesized  attributes  and  the  inherited  attributes  for  this 
example.  [Ref.  8:p.  130] 
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Figure  2.2  Nonterminals  with  Assigned  Attributes 


Synthesized  Attributes 


v  ( B ) 
v  ( L ) 
1(L) 
v  (N) 


Inherited  Attributes 


s  ( B ) 
S(L) 


Figure  2.3  Synthesized/Inherited  Attributes 

) 


The  semantic  rules  may  be  used  to  give  a  "meaning"  to 
strings  of  the  context-free  language.  For  any  derivation  of 


a  terminal  symbol  "t"  from  "S"  (the  start  symbol)  by  a 
sequence  of  production  rules  the  derivation  tree  is 
constructed.  Then  the  attributes  of  this  derivation  tree, 
or  parse  tree,  are  evaluated.  This  process  of  attribute 
definition,  which  can  occur  in  any  order,  is  applied 
throughout  the  tree  until  no  more  attribute  values  can  be 
defined.  The  defined  attributes  at  the  root  of  the  tree 
constructed  give  the  "meaning"  (or  desired  answer  or  output) 
of  that  derivation  tree.  [Ref.  8:pp.  132-133] 

Any  attribute  grammar  can  be  composed  of  both 
synthesized  and  inherited  attributes.  Semantic  rules  that 
do  not  use  inherited  attributes  can  be  considerably  more 
complicated  (along  with  being  harder  to  understand  and  to 
manipulate)  than  semantic  rules  which  allow  both  kinds  of 
attributes.  Synthesized  attributes  alone  are  sufficient  to 
define  any  function  of  the  derivation  tree  but,  in 
practice,  using  both  types  of  attributes  leads  to 
simplifications.  [Ref.  8:p.  134] 

Appendix  A  [Ref.  2]  lists  the  context-free  grammar  used 
in  SPEC.  No  attributes  are  listed  in  this  grammar. 
Appendix  B  lists  the  entire  language  Spec  including  the 
attributes  for  the  pretty  printer. 

B.  KODIYAK 

The  Kodiyak  compiler  is  essential  to  the  implementation 
of  this  pretty  printer.  A  complete  understanding  of  Kodiyak 
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is  not  necessary  for  the  user  of  the  pretty  printer  but  an 
implementor  will  be  interested  in  the  details.  The 
following  is  a  summary  of  the  major  points  of  Kodiyak  with 
an  emphasis  on  what  is  used  in  the  actual  code  of  the  pretty 
printer.  It  covers  the  following  topics: 

(1)  Description  of  Kodiyak 

( 2 )  Format 

( 3 )  Output  procedures 

(4)  Using  Kodiyak 

All  of  the  points  covered  in  the  following  section  come 
directly  from  The  Incompleat  AG  User's  Guide  and  Reference 
Manual  [Ref.  9:pp.  2-25].  The  following  is  a  synopsis  of 
the  major  points  of  this  manual,  enough  to  understand  the 
code  for  the  pretty  printer  but  not  all  the  details.  If 
further  or  more  detailed  information  is  needed  consult  the 
user's  guide  mentioned  above. 

1 .  Description  of  Kodiyak 

Kodiyak  is  a  language  designed  for  constructing 
translators.  It  is  modeled  after  Knuth's  description  of 
attribute  grammars.  The  Kodiyak  translator  accepts  a 
context-free  grammar  along  with  attribute  declarations  and 
equations,  a  scanner  specification,  and  output  declarations, 
and  generates  an  executable  translator. 

2 .  Format 

The  Kodiyak  program  is  divided  into  three  sections. 
The  first  section  describes  the  features  of  the  lexical 


scanner. 


The  second  section  names  the  attributes 


associated  with  each  grammar  symbol  and  declares  their 
types.  The  third  and  final  section  describes  the  grammar 
and  attribute  equations  which  define  the  semantics  of  the 
translation.  The  sections  are  separated  by  the  unique 
symbol  double  percent  symbol  ("%%" )  which  is  located  on  a 
line  by  itself. 

a.  Lexical  Scanner  Section 

Each  statement  in  the  first  section  of  the 
Kodiyak  program  describes  the  terminal  symbols  of  the 
translation  in  some  way.  The  two  functions  of  this  section 
are  first,  to  specify  the  correspondence  between  the 
terminal  symbols  of  the  grammar  and  the  input  text,  and 
second,  to  specify  a  set  of  operator  precedences  to  be  used 
in  conjunction  with  the  grammar. 

The  lexica]  scanner  section  defines  the  set  of 
substitutions  to  be  performed  on  the  input  text.  These 
substitutions  are  carried  out  using  regular  expressions. 
Input  is  scanned  for  text  that  matches  these  regular 
expressions.  If  a  match  is  found  then  the  corresponding 
text  is  deleted  and  replaced  with  the  associated  named 
terminal  symbol  (the  symbol  that  occurs  on  the  left-hand 
side  of  the  regular  expression). 

Figure  2.4  shows  examples  of  regular 
expressions.  An  explanation  of  the  symbols  will  assist  in 
understanding  this  terminology.  The  colon  indicates 
that  a  regular  expression  follows.  The  bar  ("|")  indicates 


an  OR.  The  symbol  "Backslash"  is  a  symbolic  constant 
representing  the  "\"  character.  The  input  string  "MOD"  or 
the  symbol  "Backslash"  is  replaced  by  the  atomic  terminal 
symbol  "MOD".  The  asterisk  ("*")  is  an  indication  of  zero 
or  more  repetitions.  This  means  that  the  symbol  (Blank)* 
represents  zero  or  more  instances  of  the  symbolic  constant 
"Blank".  The  plus  sign  ("+")  is  very  similar  to  the 
asterisk  except  that  it  means  one  or  more.  The  square 
brackets  "]")  mean  an  OR  operation  of  the  items  inside 

of  the  brackets.  Therefore  [a-zA-Z]  means  one  letter  of  the 
alphabet.  The  curly  brackets  are  used  to  invoke 

substitution.  The  caret  (H~M)  is  used  to  mean  everything 
except  what  follows  it.  Therefore  [~"\\]  means  everything 
except  the  quotation  mark  or  a  backslash. 

j 

COMMENT  :  "  —  ".*"\n"  j 

AND  I 

MOD  : (Backslash) | MOD  j 

:(Blank)+  { 

NAME  : [Letter) (alpha)*  j 


%define  Char  :  ([/'"\\]  |  (Backslash)  (Quote)  )  i 

%define  Letter  :  [a-zA-Z]  j 

%define  Int  :  (Digit)+ 

%define  Digit  :  [0-9] 

%define  Quote  :  ["]  j 

Figure  2.4  Regular  Expressions  _ j 

Another  way  to  write  regular  expressions  is 
also  illustrated  in  Figure  2.4.  It  is  a  shorthand  or 
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abbreviated  way  to  write  a  regular  expression.  This  second 
method  uses  "%define"  as  the  first  symbol  in  the  regular 
expression.  Either  format  can  be  used  with  regular 
expressions  and  they  both  can  appear  in  the  code  at  the  same 
time.  There  are  three  important  rules  about  regular 
expressions  that  must  be  remembered  to  prevent  errors. 
First  regular  expressions  can  occur  on  one  line  only.  They 
may  never  extend  beyond  one  typed  line.  Second,  regular 
expression  substitution  may  not  be  used  outside  of  the 
regular  expression  section  of  the  lexical  scanner.  Third, 
each  regular  expression  must  be  defined  before  it  can  be 
used . 

b.  Attribute  Declaration  Section 

The  attribute  declaration  section  of  the 
Kodiyak  program  names  the  attributes  associated  with  each 
grammar  symbol  and  declares  their  types.  In  this  version  of 
the  Kodiyak  program  the  attribute  declarations  for  all 
nonterminals  and  named  terminals  are  the  only  statements 
that  may  be  present  in  this  section.  Future  versions  of 
Kodiyak  may  include  other  features. 

Kodiyak  supports  two  primitive  data  types  for 
the  attributes.  They  are  integers  and  strings.  All  simple 
mathematical  functions  are  available  for  use  with  the 
integers  (i.e.,  addition,  subtraction,  multiplication, 
division).  The  size  (minimum  or  maximum  value)  of  the 
integers  will  be  machine  dependent.  Strings  can  be  of  any 
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length  with  the  only  associated  function  being 
concatenation.  String  constants  are  denoted  by  enclosing 
the  string  in  double  quotes.  Any  special  characters  must  be 
preceded  by  the  "\"  symbol.  Figure  2.5  shows  an  example  of 
integers  and  strings  and  how  they  are  declared. 


renames  { 

indent  :  string; 
str_value  :  string; 
bcursor  :  integer; 

padding  :  string; 

ecursor  :  integer;  j 

} 

j 

Figure  2.5  Integer  and  String  Declaration  Example 

Kodiyak  also  supports  higher  order  types  called 
maps  which  can  be  used  as  symbol  tables.  These  will  not  be 
discussed  here  since  they  are  not  used  by  this 

implementation  of  the  pretty  printer. 

Named  terminal  symbols  are  permitted  to  have 
user-defined  attributes  as  well  as  two  special  predefined 
attributes  %text  and  %line.  They  are  initialized  to  the 
text  of  the  terminal  symbol  matched  and  the  line  number  of 
the  input  text  that  the  match  text  occurred  on 

(respectively).  The  attribute  %text  is  used  in  the  pretty 
printer  but  the  attribute  %line  is  not. 

c.  Grammar  and  Attribute  Equation  Section 


The  third  and  final  section  of  the  Kodiyak 
program  describes  the  grammar  and  attribute  equations  which 


define  the  syntax  and  the  semantics  of  the  translation.  The 
left-hand  symbo],  of  the  first  rule  of  the  grammar  section  is 
taken  to  be  the  start  symbol.  The  start  symbol  may  not 
appear  on  the  right  hand  side  of  any  rule. 

An  attribute  value  is  named  by  naming  the 
grammar  symbol  associated  with  it,  a  period  and  the 
attribute.  The  grammar  symbol  may  be  named  in  one  of  three 
ways.  The  simplest  (if  there  are  no  repeated  grammar 
symbols  in  the  production)  is  use  the  name  of  the  symbol. 
If  that  grammar  symbol  appears  more  than  once  then  further 
distinction  must  be  made.  In  this  case,  the  name  is  taken 
to  refer  to  the  left-most  occurrence  of  the  grammar  symbol. 
To  name  a  grammar  symbol  which  is  not  the  left-most  instance 
of  that  grammar  symbol,  the  name  may  be  indexed  by  a  number 
in  square  brackets  denoting  which  occurrence  is  desired. 
The  left-most  occurrence  of  the  symbol  is  numbered  one,  the 
next  left-most  two,  the  next  left-most  three,  etc.  These 
first  two  ways  are  used  by  the  pretty  printer.  The  third 
way  is  with  the  use  of  the  dollar  sign  ("$")  followed  by 
the  numerical  position  of  the  grammar  symbol  in  the 
production.  This  is  not  used  by  the  pretty  printer.  Figure 
2.6  gives  examples  of  naming  attributes. 

All  of  the  functions/operators  available  for 
the  integer  and  strings  are  shown  in  Figure  2.7.  These 
functions  include  arithmetic,  string  manipulation, 
relational  operators  and  logical  operators.  The  left-hand 
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column  of  Figure  2.7  shows  the  symbol  and  the  right-hand 
column  provides  the  meaning  of  that  symbol. 


expr : 

expr  '+'  UNUMBER 

{ 

$$. value  =  $1. value  +  s2i ( $3 .%text ) ; 

) 

expr: 

expr  '+'  UNUMBER 

{ 

expr. value  =  expr [2] .value  +  s2i ( UNUMBER. %text ) ; 

} 

expr : 

expr  '+'  UNUMBER 

{ 

expr[ 1 ] .value  =  expr[2] .value  + 

s2i (UNUMBER[ 1 ] .%text ) ; 


Figure  2.6  Naming  Attribute  Examples 


+ 

addition 

* 

multiplication 

- 

subtraction 

/ 

division 

A 

concatenation 

[  ] 

concatenation 

< 

less  than 

> 

greater  than 

=  = 

equal 

<> 

not  equal 

<  = 

less  than  or  equal 

>  = 

greater  than  or  equal 

&S. 

and 

Note  this  a  partial  list  showing  just  the  operators 
i  used  in  this  implementation. 

Figure  2.7  Available  Operators 


One  final  note  about  attribute  equations 
concerns  the  if-then-else  statement.  The  symbology  is  a 
little  different  from  more  programming  languages.  There  are 
no  keywords  "if",  "then"  or  "else"  but  only  the  symbols  "- 
>"  and  "#".  For  example,  "IF  A  THEN  B  ELSE  C"  is  written  "A 
->  B  #  C".  Figure  2.8  shows  a  typical  if-then-else 
statement.  The  expression  to  the  right  of  the  "="  is  the 
"if".  The  expression  to  the  right  of  the  ”->"  is  the 
"then"  and  the  expression  to  the  right  of  the  "#"  is  either 
the  "else"  or  "else_if"  part. 


IF  THEN  ELSE  EXAMPLE  j 

I 

comment [1 ] .str_value  =  comment[l] .bcursor  <=  0 

->  [ COMMENT. %text, comment [2] .st r_value]  j 

#  ["\n" , COMMENT. %text,comment[2] .str_value] ;  j 

i 

i 

! 

IF  THEN  ELSE_IF  EXAMPLE 

I 

comment[l] .str_value  =  comment [ 1 ]. bcursor  <=  0 

->  [ COMMENT. %text, comment [2] .str_value]  j 

#  comment [l ] .bcursor  +  len ( COMMENT. %text )  >=80  ! 

->  [ "c" , COMMENT. %text, comment [2] .str_value] 

#  ("\n" ,COMMENT.%text,comment[2] .str_value] ; 

Figure  2.8  If  Then  Else  Statement  | 

— - 1 

3 .  Output  Procedures 

To  get  any  output  from  the  Kodiyak  program,  such  as 
the  pretty  printer  does,  the  program  must  include  a  special 
side-effecting  procedure.  The  side-effecting  procedure  with 


17 


its  associated  equations  can  only  be  used  by  the  start 
symbol.  There  are  five  of  these  procedures  available  in 
Kodiyak  and  they  are  introduced  by  a  percent  symbol, 
followed  by  the  name  of  the  procedure  and  the  arguments 
surrounded  by  parentheses.  The  pretty  printer  only  uses  one 
of  the  procedures,  named  "%output".  Figure  2.9  gives  a 
short  description  of  the  procedure  as  well  as  an  example. 


%output ( val : string ) 

val  is  written  to  the  standard  output  j 

EXAMPLE 

start 

:  comment  spec 

{ 

%output( [comment. str  value, 

spec . str_value ] ) ;  ! 

comment .bcursor  *  0; 

} 

Figure  2.9  Output  Procedure  Example 

_ _ _ _ _ _ 1 

4 .  Using  Kodiyak 

The  Kodiyak  compiler  creates  and  processes  many 
files  among  them  are  files  which  are  processed  by  Yacc,  by 
Lex  and  by  the  C  compiler.  There  are  also  two  predefined 
files  that  the  Kodiyak  compilation  depends  on.  The  first  is 
the  Kodiyak  library  which  contains  functions  for  creating 
the  parse  tree,  evaluating  attributes,  concatenating 
strings,  creating  pairs,  etc.  This  file  is  usually  not 
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modified  by  the  user.  In  this  implementation  this  file  is 
named  kmain.c. 


The  second  file  is  the  library.  This  file  is  a  set 
of  C  functions.  This  is  where  the  user  can  add  any  new 
functions  for  the  Kodiyak's  use.  in  this  implementation  the 
function  SPACES  was  added  to  the  end  of  the  file  named 
kclib.c.  The  file  itself  has  information  on  how  to  add 
functions.  Note  this  is  the  only  place  available  for  the 
user  to  add  his  own  functions.  Creating  a  separate  file  and 
compiling  it  separately  will  cause  syntax  errors. 

The  command  to  invoke  the  Kodiyak  is  "k  sample. k". 
The  file  that  handles  everything  (i.e.,  the  driver  of  the 
software)  is  the  file  k.  The  name  of  the  file  to  be 
compiled  is  sample. k  in  this  case.  Files  to  be  compiled 
should  have  the  extension  ".k"  or  the  compiler  may  not 
accept  it.  Kodiyak  programs  may  also  have  one  other 
extension  ".m4"  but  that  was  not  used  in  this 
implementation . 

If  the  program  compiles  without  errors,  the 
resulting  object  file  (executable  code)  will  be  in  the  file 
named  "sample".  This  is  the  name  of  the  file  submitted 
without  the  extension.  Otherwise  some  cryptic  error 
messages  may  be  printed.  Some  common  errors  (as  well  as  the 
type  of  error  message  printed  and  "what  to  do")  are  listed 
in  Figure  2.10.  There  is  also  a  set  of  options  available  to 
assist  in  debugging.  The  options  are  typed  on  the  same  line 
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but  immediately  after  the  "k  sample. k".  Figure  2.11  shows 
the  options  available. 


ERROR 

1.  syntax  error  -  which  are  mostly  typing  errors 

2.  missing  attribute  evaluation  rules  and 
circular  evaluation  rules 

3.  table  overflow  errors 

4.  memory  storage  exceeded 

MESSAGE  PRINTED  OUT 

1.  an  associated  line  number  with  the  symbol 
that  has  the  syntax  error 

2.  pair  of  grammar  rules  the  parent  of  the  error 
rule  and  the  error  rule 

3.  statement  "table  overflow  need  more  space" 

4.  statement  "exceeded  memory  space" 

WHAT  TO  DO 

1 .  find  the  typing  mistake 

2.  look  for  a  missing  attribute  evaluation  rule  in 
the  parent  rule 

3.  increase  table  size  allotted 

4.  increase  memory  space  for  given  variable 


Figure  2.10  Common  Errors  in  Kodiyak 


One  final  note  about  error  messages.  The  first 
character  of  any  identifier  name  should  usually  be  ignored. 

They  are  tacked  on  by  the  Kodiyak  compiler  to  avoid  naming 
conflicts  between  Lex,  Yacc,  C  and  Kodiyak  library  routines. 
As  an  example,  if  the  error  message  printed 
"ucomment .padding  is  undefined"  this  should  be  read  as 
"comment .padding  is  undefined". 


I 
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-h  Print  out  a  list  of  legal  options. 

file  Read  input  from  " f ile"rather  than  the  standard 

input  j 

-e  Continue  attribute  evaluation  even  after  an  j 

error  occurs.  This  is  useful  when  debugging 
attribute  definitions. 

-1  Print  out  all  tokens  as  they  are  scanned. 

-y  Print  out  all  grammar  rule  reductions  as  they 

occur . 

-L  Turn  on  LEX's  debugging  features. 

-Y  Turn  on  YACC's  debugging  features. 

-c  Generate  a  core  image  when  a  run-time  error  j 

occurs  I 

i 

-s  Print  out  storage  statistics  after  all  | 

attribute  evaluations  is  completed. 

-o  file  Divert  the  standard  output  to  "file". 

Figure  2.11  Options  List  j 

C.  PRETTY  PRINTER 

A  pretty  printer  is  a  software  tool  used  to  format 
programs  to  make  them  easier  to  understand  and  read.  It 
takes  character  strings,  called  tokens,  from  an  input  source 
and  prints  them  with  aesthetically  appropriate  spacing  and 
line  breaks.  The  input  is  usually  a  text  file  or  a  parse 
tree.  The  two  primary  functions  of  the  pretty  printer  are 
to  insert  spaces  and  linefeeds  between  tokens  and  to 
determine  where  and  how  to  break  lines.  [Ref.  10 :p-  119] 
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A  syntax-directed  pretty  printer  is  a  pretty  printer 
that  knows  the  syntax  of  a  programming  language  and  formats 
programs  based  on  that  knowledge.  The  syntactic  structure 
and  flow  of  control  of  pretty  printed  programs  are  made 
clear  because  the  output  medium  shows  the  indentation  and 
line  breaks.  [Ref.  10:p.  119] 

A  syntax-directed  pretty  printer  may  be  either  language 
dependent  or  language  independent.  A  language  dependent 
syntax-directed  pretty  printer  is  written  for  a  specific 
language.  Since  all  constructs  in  the  language  are  known, 
the  pretty  printer  traditionally  has  been  written  as  a  large 
switch  or  case  statement  (for  languages  like  Pascal  and 
Lisp).  If  any  changes  are  made  to  the  language  the  code 
for  the  pretty  printer  must  be  revised.  [Ref.  10 :p.  120] 

The  language  independent  syntax-directed  pretty  printer 
is  designed  to  be  used  for  any  language.  In  this  case  no 
knowledge  of  any  particulars  of  a  language  are  used  in 
constructing  the  pretty  printer.  This  version  of  a  pretty 
printer  must  be  given  information  about  a  language  to 
produce  a  pretty  printer  for  that  language.  In  the  long  run 
it  is  easier  and  quicker  to  write  one  language  independent 
pretty  printer  that  can  be  used  over  and  over  again  then  to 
code  a  new  pretty  printer  for  each  specific  language  that  is 
to  be  pretty  printed.  [Ref.  10:p.  120] 

For  either  type  of  syntax-directed  pretty  printer  there 
are  common  issues  that  must  be  addressed.  Issues  such  as 


22 


where  to  add  spaces  and  linefeeds,  where  to  break  a  line, 
how  to  handle  comments  and  what  to  do  about  syntax  errors 
must  be  handled  with  great  care  [Ref.  10 :p.  121].  The 

pretty  printer  developed  in  this  thesis  is  a  language 
dependent  syntax-directed  pretty  printer  (referred  to 
throughout  this  thesis  as  a  language  dependent  pretty 
printer).  The  generalization  of  this  implementation  is 
discussed  and  general  rules  for  a  language  independent 
syntax-directed  pretty  printer  are  developed  but  are  not 
implemented . 

D.  SPEC 

SPEC  is  a  formal  language  for  writing  black-box 
specifications  for  components  of  software  systems.  SPEC 
uses  the  event  model  to  define  the  black-box  behavior  of 
proposed  and  external  systems.  Black-box  specifications  are 
developed  for  the  external  interfaces  of  the  system  in  the 
functional  specification  stage  of  software  development,  and 
for  the  internal  interfaces  in  the  architectural  design 
stage.  Discussion  of  the  event  model  and  the  SPEC  language, 
extracted  from  [Ref.l.-pp.  3.1-3.15],  follows.  Appendix  A 
[Ref.  2]  contains  a  listing  of  the  grammar  for  the  SPEC 
language. 

1 .  The  Event  Model 

In  the  event  model,  computations  are  described  in 
terms  of  events,  modules  and  messages.  An  event  occurs 


when  a  message  is  received  by  a  module  at  a  particular 
instant  of  time.  A  module  is  a  black  box  that  interacts 
with  other  modules  only  by  sending  and  receiving  messages. 
A  message  is  a  data  packet  that  is  sent  from  one  module  to 
another  module. 

Modules  can  be  used  to  model  external  systems  such 
as  users  and  peripheral  hardware  devices,  as  well  as 
software  components.  A  module  has  no  visible  internal 
structure.  The  behavior  of  a  module  is  specified  by 
describing  its  interface.  The  interface  of  a  module 
consists  of  the  kinds  of  events  that  can  occur  at  the  module 
along  with  its  response  to  each  kind  of  event.  Each  kind  of 
event  corresponds  to  a  different  of  incoming  message.  Each 
response  consists  of  the  later  events  directly  triggered  by 
a  given  initial  event. 

Any  module  accepts  messages  one  at  a  time,  in  a 
well-defined  order  that  can  be  observed  as  a  computation 
proceeds.  Message  transmission  is  assumed  to  be  reliable. 
Messages  can  have  arbitrarily  long  and  unpredictable 
transmission  delays.  The  order  of  messages  arriving  is 
normally  not  under  control  of  the  designer. 

In  the  event  model  each  module  has  its  own  local 
clock.  The  local  clocks  of  different  modules  are  not 
necessarily  synchronized  with  each  other.  Each  event  occurs 
at  a  well-defined  instant  of  time,  which  is  the  time  at 
which  the  destination  module  receives  a  message,  according 
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to  its  own  local  clock.  The  length  of  time  between  two 
events  is  precisely  defined  if  both  events  occur  at  the  same 
place.  The  length  of  time  between  two  events  at  different 
locations  can  be  estimated  in  terms  of  two  readings  of  the 
same  clock,  but  this  is  only  an  approximation  because  of 
unpredictable  message  delays  in  obtaining  remote  clock 
readings.  The  only  kind  of  time  interval  meaningful  in  the 
event  model  is  the  duration  between  two  events.  There  is  no 
way  to  distinguish  between  computation  delay  and 
communication  delay  in  the  event  model. 

Each  message  has  a  sequence  of  zero  or  more  data 
values  associated  with  it.  The  other  attributes  of  a 
message  are  its  name,  its  condition  and  its  origin.  All  of 
these  attributes  are  single  valued.  Exceptions  are  modeled 
as  messages  by  means  of  a  condition  attribute,  which  can 
take  on  the  values  "normal"  and  "exception".  The  condition 
of  a  message  expressing  a  normal  request  for  service  is 
"normal".  The  condition  of  a  message  reporting  an  abnormal 
event  somewhere  is  "exception",  in  which  case  the  name  of 
the  message  is  the  name  of  an  exception  condition. 

The  response  of  a  module  to  a  message  is  completely 
determined  by  the  sequence  of  messages  received  by  the 
module  since  it  was  created.  A  module  is  mutable  if  the 
response  of  the  module  to  at  least  one  message  it  accepts 
can  depend  on  messages  that  arrived  before  the  most  recent 
incoming  message.  A  module  is  immutable  if  the  response  of 
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the  module  to  every  possible  message  is  completely 
determined  by  the  most  recent  incoming  message.  Mutable 
modules  behave  as  if  they  had  internal  states  or  memory, 
while  immutable  modules  behave  like  mathematical  functions. 
A  module  is  immutable  if  and  only  if  it  is  not  mutable. 

Each  module  has  the  potential  of  acting 
independently,  so  that  there  is  natural  concurrency  in  a 
system  consisting  of  many  modules.  Since  events  happen 
instantaneously  and  the  response  of  a  module  is  not 
sensitive  to  anything  but  the  sequence  of  events  at  the 
module,  the  event  module  implies  concurrent  interactions 
with  a  module  cannot  interfere  with  each  other  at  the  level 
of  individual  events.  This  non-interference  must  be 
guaranteed  by  implementations  which  require  a  finite  time 
interval  to  trigger  the  responses  to  an  event.  The  response 
of  a  module  is  under  the  control  of  the  designer. 

In  modeling  concurrent  systems  it  is  sometimes 
necessary  to  specify  atomic  transactions.  Atomic 
transactions  are  non-interruptible  sequences  of  events  at  a 
module.  Once  a  module  starts  an  atomic  transaction,  it 
cannot  accept  any  messages  that  are  not  part  of  the 
transaction  until  it  is  complete.  Atomic  transactions  are 
sometimes  needed  to  specify  non-interference  between 
concurrent  sets  of  activities  involving  chains  of  multiple 
events  at  the  same  module.  Atomic  transactions  must  be  used 
with  care  because  they  can  lead  to  deadlocks  if  the 


protocols  of  the  modules  involved  in  a  transaction  are  not 
compatible  with  each  other,  and  can  lead  to  starvation  if  a 
transaction  goes  on  forever. 

Modules  can  be  used  to  model  current  and 
distributed  systems,  as  well  as  systems  consisting  of  a 
single  sequential  process.  The  event  model  helps  to  expose 
the  parallelism  inherent  in  a  problem,  because  the  only  time 
orderings  specified  are  those  which  are  unavoidable  and  are 
agreed  on  by  all  observers. 

Events  can  be  triggered  at  absolute  times.  Such 
events  are  called  temporal  events .  Temporal  events  are  the 
means  by  which  modules  can  initiate  actions  that  are  not 
direct  responses  to  external  stimuli.  Formally  a  temporal 
event  occurs  when  a  module  sends  a  message  to  itself  at  a 
time  determined  by  its  local  clock.  Unless  explicitly 
stated  otherwise,  there  may  be  an  unpredictable  delay 
between  the  time  when  the  message  is  sent  and  the  time  when 
it  is  received,  just  like  for  any  other  message. 

2.  The  SPEC  Language 

The  SPEC  language  uses  first  order  logic  for  the 
precise  definition  of  the  desired  behavior  of  modules.  The 
Spec  language  provides  a  means  for  specifying  the  behavior 
of  three  different  types  of  modules: 

( 1 )  Functions 

(2)  State  machines 

( 3 )  Types 


I 
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Each  of  these  types  of  modules  is  described  in  the 
following  pages  along  with  examples  of  each  type  of  module, 
a.  Functions 

Function  modules  are  immutable  and  calculate 
functions  on  data  types,  where  "function"  is  interpreted  as 
in  standard  mathematics.  Usually  function  modules  provide 
only  a  single  service  and  hence  accept  anonymous  messages. 
Figure  2.12  gives  an  example  of  the  specification  for  a 
square  root  function. 


FUNCTION  square_root{precision : real} 

WHERE  precision  >  0.0 

MESSAGE  ( x : real ) 

WHEN  x >  =  0.0 
REPLY  (y:real) 

WHERE  y  >=  0.0  &  approximates  (y*y,x) 

OTHERWISE  REPLY  EXCEPTION  imaginary_square_root 

CONCEPT  approximates  (rl  r2:real) 

— True  if  rl  is  a  sufficiently  accurate 
— approximating  of  r2. 

--The  precision  is  relative  rather  than  absolute 
VALUE  (b: boolean) 

WHERE  b<=>  abs  ( ( rl  -  r2)/r2)  <=  precision 

END 

Note:  " — "  introduces  a  comment  and  all  keywords  in 
Spec  appear  in  all  capital  letters 


Figure  2.12  Function  Example 


b.  State  Machines 

A  machine  is  a  module  with  an  internal  state, 
i.e.,  machines  are  mutable  modules.  Figure  2.13  shows  an 
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example  of  a  machine.  The  behavior  of  the  machines  is 
described  in  terms  of  a  conceptual  model  of  its  state, 
rather  than  directly  in  terms  of  the  messages  that  arrived 
in  the  past,  because  descriptions  in  terms  of  such  a 
conceptual  model  are  usually  shorter  and  easier  to  read. 


MACHINE  inventory 

— assumes  that  shipping  and  supplier  are  other  modules 
STATE  ( stock :map( item , integer } ) 

INVARIANT  ALL  ( i : item: : stock [ 1 ]  >=  0) 

INITIALLY  ALL  ( i : item: : stock [ 1 ]  =  0) 

MESSAGE  receive  ( i : item, q: integer ) 

--Process  a  shipment  from  a  supplier. 

WHEN  q  >  0 

TRANSITION  stock [ 1 ] =*stack [ i ]  +  q 
— Delayed  responses  to  backorders  are  not  shown. 
OTHERWISE  REPLY  EXCEPTION  empty_shipment 

MESSAGE  order  { io : item, qo : integer ) 

— Process  an  order  from  a  customer. 

WHEN  0  <  qo  <=  stock [io] 

SEND  ship  (is: item,  qs: integer)  TO  shipping 
WHERE  is  *  io,  qs  =  qo 
TRANSITION  stock [io]  +  qo  =  *stock[io] 

WHEN  0  <  qo  >  stock [io] 

SEND  ship  (is: item,  qs: integer)  TO  shipping 
WHERE  is  =  is,  qs  =  stock [io] 

SEND  back_order  (ib:item,  qb: integer)  TO  supplier 
WHERE  ib  =  io,  qb  +  qs  =  qo 
TRANSITION  stock[io]  =  0 
OTHERWISE  REPLY  EXCEPTION  empty_order 
END 


Figure  2.13  Machine  Example 


c.  Types 

A  type  module  defines  an  abstract  data  type. 
An  abstract  data  type  provides  many  services  therefore  the 
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messages  of  a  type  module  usually  have  a  name.  An  abstract 
data  type  consists  of  a  set  of  instances  and  a  set  of 
primitive  operations  involving  the  instances.  The  instances 
are  the  individual  data  objects  belonging  to  the  type.  The 
instances  of  an  abstract  data  type  are  black  boxes.  The 
properties  of  the  instances  are  not  visible  directly,  and 
can  only  be  observed  and  influenced  by  means  of  the 
primitive  operations.  The  properties  of  an  instance  are 
determined  by  the  primitive  operation  that  created  the 
instance  and  the  sequence  of  primitive  operations  applied 
after  it  was  created. 

Date  types  are  either  mutable  or  immutable. 
For  immutable  types  the  set  of  instances  and  the  properties 
of  each  instance  are  fixed.  Operations  producing  instances 
of  the  type  are  viewed  as  selecting  members  of  this  fixed 
set.  Figure  2.14  is  an  example  of  an  immutable  abstract 
data  type. 

The  state  of  a  mutable  data  type  consists  of  a 
set  of  instances  which  have  internal  states.  The  initial 
state  of  a  mutable  type  is  an  empty  set  of  instances. 
Mutable  types  have  operations  for  creating  new  instances, 
and  usually  also  operations  that  can  change  the  properties 
of  an  instance  once  it  has  been  created.  An  example  of  a 
mutable  abstract  data  type  with  immutable  instances  is  the 
set  of  unique  identifiers  for  the  objects  in  a  database. 
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TYPE  rational 

INHERIT  equality  {rational} 

MODEL  (num  den: integer) 

INVARIANT  ALL  ( r : rational :: r . den  ~=  0) 

MESSAGE  ratio  (num  den: integer) 

WHEN  den  ~=  0 
REPLY  (r:rational) 

WHERE  r.num  =  num,  r.den  =  den 
OTHERWISE  REPLY  EXCEPTION  zero_denominator 

MESSAGE  add  ( x ,y : rational )  OPERATOR  + 

REPLY  (r:rational) 

WHERE  r.num  =  x.num*y .den+y .num*x.den, 
r.den  =  x.den*y.den 

MESSAGE  multiply  (x  y: rational)  OPERATOR  * 

REPLY  (r: rational) 

WHERE  r.num  =  x.num*y.num,  r.den  =  x.den*y.den 

MESSAGE  equal  (x  y: rational)  OPERATOR  = 

REPLY  (b: boolean) 

WHERE  b  <=>  (x.num*y.den  =  y.num*x.den) 

END 

Figure  2.14  Immutable  Abstract  Data  Type 


An  instance  of  a  mutable  data  type  is  very 
similar  to  a  state  machine,  except  that  the  state  machine  is 
implicitly  created  at  the  start  of  the  computation,  while 
the  instances  of  a  mutable  data  type  are  created  as  a 
computation  proceeds.  A  state  machine  has  exactly  one 
instance,  while  a  mutable  data  type  can  have  any  number  of 
instances.  Figure  2.15  is  an  example  of  a  specification  of 
a  mutable  data  type. 


TYPE  queue  (t:type) 

INHERIT  mutable  {queue}  j 

— Inherit  definitions  of  the  concepts  new  and  defined.  ! 
MODEL  ( e : sequence )  j 

-The  front  of  the  queue  is  at  the  right  end. 

INVARIANT  tue 

— Any  sequence  is  a  valid  model  for  a  queue.  j 

MESSAGE  create 

— A  newly  created  empty  queue. 

REPLY  (q:queue{t) )  WHERE  q.e  =  [] 

TRANSITION  new(q) 

MESSAGE  enqueue  (x:t,  q:queue{t)) 

— Add  x  to  the  back  of  the  queue.  j 

TRANSITION  q.e  =  append([x],  *q.e) 

MESSAGE  dequeue  (q:queue{t})  j 

— Remove  and  return  the  front  element  of  the  queue. 
WHEN  not_empty  ( q ) 

REPLY  ( x : t ) 

TRANSITION  *q.e  =  append  (q.e,[x]) 

OTHERWISE  REPLY  EXCEPTION  queue_underflow 

MESSAGE  not_empty  (q:queue{t}) 

--True  if  q  is  not  empty. 

REPLY  (b: boolean)  WHERE  b  <=>  (q.e  ~=  []) 

END 

Figure  2.15  Mutable  Abstract  Data  Type 
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III.  DESIGN  AND  IMPLEMENTATION 


The  actual  design  and  implementation  for  the  pretty 
printer  was  motivated  not  only  on  the  specific  application 
to  this  particular  language  but  also  by  the  desire  to 
generalize  the  solution  to  apply  to  other  languages.  It  is 
highly  desirable  that  what  is  learned  from  this  particular 
case  can  be  extended  to  the  design  of  a  language 
independent  pretty  printer. 

A.  DESIGN  QUESTIONS 

A  language  dependent  pretty  printer  is  a  software  tool 
to  increase  the  readability  and  understandability  of  a 
specific  formal  language.  In  this  light  the  design 
questions  must  be  centered  around  increasing  both  the 
readability  and  understandability  of  Spec  (the  language  used 
in  this  application) . 

One  important  constraint  related  to  this  specific 
application  must  be  considered  carefully.  The  Kodiyak 
compiler  cannot  be  changed.  There  are  provisions  to  add 
features  to  the  compiler  but  the  overall  design  and 
implementation  of  the  Kodiyak  compiler  is  fixed.  Therefore 
any  design  decisions  must  not  require  any  modifications  to 
the  Kodiyak  compiler  itself. 


Specific  Design  Issues 

There  are  five  considerations  specific  to  this 
implementation  that  must  be  addressed.  They  are: 

(1)  Length  of  each  line 

(2)  Standards  for  indentation 

( 3 )  Token  length 

( 4 )  Comments 

(5)  Keywords 

a .  Line  Length 

The  length  of  the  line  defines  the  maximum 
number  of  characters  that  can  be  printed  on  any  given  line. 
This  length  can  be  chosen  regardless  of  the  width  of  the 
output  medium  but  must  permit  the  maximum  number  of 
characters  to  all  be  printed  within  the  output  medium's 
width.  Depending  on  the  implementation  this  can  be  either  a 
global  constant  or  an  input  parameter. 

b.  Indentation 

Indentation,  as  applied  to  computer  programs, 
groups  together  lines  of  related  code.  An  example  in  the 
English  language  of  indenting  is  a  formal  outline.  There 
are  major  topic  headers.  Under  each  major  topic  header  is 
subtopic  headers  with  each  subtopic  being  subdivided 
(depending  on  how  detailed  the  outline  is).  Figure  3.1  is 
an  example  of  a  simple  formal  outline. 

As  Figure  3.1  shows  indentation  makes  the 
structure  easy  to  see.  Related  items  all  start  at  the  same 
distance  from  the  left  margin.  As  the  number  of 
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subdivisions  grow  the  longer  the  indentation  (relative  to 
the  left  margin). 


I.  Introduction 

a.  Software  engineering 

1.  General  introduction 

b.  Functional  specification 

1 .  Nonformal 

2 .  Formal 

(a)  Spec  Language 
II .  Background 

a.  Attribute  grammar 

1.  Definition 

2.  Purpose/role 

3.  Attributes  in  general  defined 

(a)  Synthesized 

(b)  Inherited 

b.  Kodiyak 

1.  Definition 

2 .  Format 

3 .  Semantics 


Figure  3.1  Sample  Outline 


In  computer  programs  how  much  to  indent  related 
lines  is  an  important  question.  Using  too  many  spaces  for 
indenting  can  easily  run  lines  of  code  off  a  page.  On  the 
other  hand  not  using  a  wide  enough  indent  does  not  show  the 
structure  of  the  code  and  decreases  readability.  A 
compromise  must  be  made  between  readability  and  losing  lines 
of  code  off  a  page.  The  standard  for  program  code  is 
between  two  and  five  spaces  for  indenting  each  subdivision 
of  related  lines  of  code. 
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c .  Token  Length 

Token  length  is  the  actual  length  of  any  token 
used  in  the  language.  One  assumption  that  should  be  made  is 
that  no  token  is  longer  than  the  maximum  number  of 
characters  allowed  on  one  line. 

d .  Comments 

Comments  are  added  to  provide  documentation  to 
the  code  and  also  explain  what  the  code  is  actually  doing. 
Therefore  it  is  extremely  helpful  to  have  comments  disbursed 
among  the  lines  of  code.  For  readability  comments  should 
not  appear  between  code  segments  that  are  on  the  same  line. 
The  particular  language  implemented  will  specify  the 
allowable  placement  of  comments  and  how  the  comments  are 
identified . 

e.  Keywords 

The  final  consideration  is  keywords.  Does  the 
language  contain  keywords?  If  so,  how  are  they  to  be 
distinguished?  Are  they  unique  (i.e.,  reserved)  or  can  the 
programmer  use  a  language  keyword  with  a  totally  different 
meaning?  Do  keywords  have  special  format?  Some  of  the 
possibilities  are: 

(1)  all  capitalized  with  the  rest  of  the  code  lowercase 

(2)  all  capitalized  with  the  rest  of  the  code  a 
combination  of  lowercase  and  uppercase 

(3)  underlined 

(4)  proceeded  by  a  special  character 
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.  General  Desian  Issues 


When  considering  the  specific  questions  generic 
rules  should  also  be  a  consideration.  Can  this  specific 
implementation  be  easily  modified  to  handle  different/slight 
modifications?  For  example  if  the  line  length  is  increased 
will  this  radically  effect  the  software  or  is  it  a  very  easy 
change?  Additionally,  can  more  features  be  added  if 
desired?  Can  debugging  aids  be  added  to  the  already 
existing  software?  Will  any  modifications  still  be 
compatible  with  the  existing  software?  Will  added  features 
effect  the  original  code  causing  a  revision?  If  these  added 
features  cause  the  original  code  to  be  revised,  how  much 
work  is  involved  and  are  the  added  features  worth  the  added 
work? 

B .  DESIGN  DECISIONS 

The  decisions  that  were  made  for  this  specific 
implementation  concern  the  questions  raised  in  the  previous 
pages.  They  are: 

(1)  Length  of  a  line 

( 2 )  Token  length 

(3)  Indentation 

( 4 )  Comments 

(5)  Keywords 

l .  Length  of  Line  Decision 

The  length  of  the  standard  line  for  this 
implementation  is  80  characters.  It  makes  no  difference 
whether  the  output  from  the  pretty  printer  is  printed  on  8 
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1/2"  paper  or  the  wider  14"  paper.  This  print  out  will  fit 
on  either  size  of  paper  which  allows  for  more  flexibility  in 
what  printer  and  paper  is  used.  The  only  drawback  to  this 
decision  is  that  if  the  wider  paper  is  used  the  right  5  1/2" 
of  the  paper  will  not  be  utilized. 

2 .  indentation  Decision 

The  standard  indentation  is  always  three  blank 
characters.  As  each  sentence  in  the  language  is  subdivided 
(broken  down  into  the  grammar  rules)  the  indentation  is 
expanded  by  an  additional  three  blank  characters.  Three  is 
a  fairly  reasonable  number  between  the  standard,  in  computer 
science,  two  and  five  spaces.  It  allows  the  reader's  eyes 
to  see  what  sentences  and  parts  of  sentences  are  all  related 
at  the  same  level.  Additionally,  there  is  not  too  much 
indenting  (i.e.,  using  five  blank  characters)  so  that  if  a 
lot  of  subdividing  (or  recursion)  occurs  the  indenting  will 
not  run  the  print  out  off  the  page. 

3 .  Token  Length  Decision 

One  necessary  assumption  made  by  this 
implementation  is  that  the  token  length  for  any  token  will 
not  exceed  the  maximum  line  length.  Any  token  greater  than 
80  can  never  be  printed  with  the  restriction  placed  on  this 
implementation.  If  the  line  length  is  increased  then  the 
maximum  token  length  can  also  be  increased. 
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4.  Comment  Decision 


Comments  are  allowed  to  be  one  line  or  multiple 
lines  long.  Comments  can  come  at  the  end  of  a  line  of  code 
filling  the  space  until  the  right-hand  margin  is  reached,  or 
can  be  one  line  long  starting  at  the  left-hand  margin,  or 
can  extend  over  several  lines  with  each  new  line  flush  with 
the  left-hand  margin. 

The  one  restriction  on  a  comment  is  that  it  is 
always  started  with  a  special  character  and  its  total 
length  (including  the  special  character)  is  less  than  or 
equal  to  the  line  length.  For  this  implementation  the 
special  character  to  introduce  a  comment  is  " — ". 

For  a  comment  extending  beyond  the  line  length  it 
must  be  broken  up  into  two  lines  each  starting  with  a 
special  character.  If  this  is  not  done  by  the  user  part  of 
the  comment  may  be  lost  when  it  is  printed.  It  is  important 
to  emphasize  that  it  is  the  user's  responsibility  to  insure 
that  comments  are  not  longer  then  80  characters  since  this 
pretty  printer  implementation  assumes  a  single  comment  will 
fit  on  one  line  (80  characters  or  less). 

For  output  the  special  crmment  character  is  always 
followed  by  one  blank  character.  If  a  comment  comes  at  the 
end  of  a  line  of  code  the  pretty  printer  will  place  two 
blank  characters  before  the  special  character.  If  the 
comment  starts  a  new  line  there  will  be  no  proceeding  blank 
characters.  Figure  3.2  shows  examples  of  comments. 
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1 . 

--  This  comment  is  a  single  line  comment.  i 

2.  i 

expression  =  exp  +  exp  —  Comment  following  code  j 

3* 

expression  =  exp  +  exp  --  Comment  following  code  ! 

—  but  this  time  code  extends  more  than  one  line. 

4. 

—  This  is  a  sample  of  a  multiline  comment  with 

—  the  first  line  being  flush  with  the  left  margin. 

Figure  3 . 2  Comment  Examples 
5 .  Keyword  Decision 

All  keywords  in  the  output  are  capitalized.  in 

this  implementation  there  are  three  types  of  keywords.  The 

importance  of  these  three  types  will  be  explained  in  more 

detail  later.  Figures  3.3,  3.4  and  3.5  show  the  three 

types  of  keywords.  All  three  categories  of  keywords  are 
typed  in  all  uppercase  letters  with  the  difference  coming  in 
the  indentation  rules  related  to  the  keywords. 

C.  ATTRIBUTE  DEFINITIONS 

The  design  of  the  pretty  printer  centers  around  the 
selection  of  attributes.  The  goal  of  the  design  is  to 
create  a  software  package  that  produces  a  formatted  output 
that  is  readable  and  reflects  the  structure  of  the  original 
code.  The  format  of  the  input  must  be  irrelevant  to  the 
pretty  printer.  It  must  also  be  noted  that  the  input  must 
be  syntactically  correct  for  the  pretty  printer  to  operate 
correctly. 
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Figure  3.4  Expression  Keywords 


Figure  3.5  Special  Keywords 


The  attributes  will  define  the  language  dependent 
pretty  printer.  There  should  be  as  few  attributes  as 
possible  with  each  limited  to  one  specific  function 
therefore  making  each  very  limited  in  scope.  All  the 
attributes  can  be  one  of  two  types:  synthesized  attributes 
or  inherited  attributes.  Synthesized  attributes  are  based 
on  the  attributes  of  the  descendants  of  the  nonterminal 
symbol.  Inherited  attributes  are  based  on  the  attributes  of 
the  ancestors.  Synthesized  attributes  are  evaluated  from 
the  bottom  up  in  the  tree  structure,  while  inherited 
attributes  are  evaluated  from  the  top  down.  [Ref.  8:p.  130] 

The  pretty  printer  will  need  values  for  the  print  head 
position,  lengths  of  symbols,  values  for  indenting  and  the 
actual  string  that  will  be  printed.  With  these  ideas  in 
mind  this  implementation  utilizes  six  attributes  as  shown  in 
Figure  3.6. 

The  type  of  attribute,  the  type  of  value  the  attribute 
is  and  a  definition  (with  examples  if  necessary)  of  each 
attribute  follows.  Remember  that  each  attribute  has  one 
unique  purpose  which  is  very  limited  in  scope. 


ATTRIBUTE 


DEFINITION 


bcursor  beginning  cursor  position 

ecursor  end  cursor  position 

padding  blank  spaces  to  pad  beginning  of  line 

indent  indentation 

str_value  string  value 

length  number  of  characters  long 

Figure  3.6  Pretty  Printer  Attributes 

1 .  Bcursor 

Bcursor  is  short  for  beginning  cursor  position.  It 
is  the  column  position  at  which  the  left-most  character  of  a 
production  rule  will  be  printed.  This  is  an  inherited 
attribute  with  an  integer  value.  As  the  print  head  moves 
across  the  paper  from  left  to  right  the  value  of  bcursor 
will  increase  from  one  to  the  maximum  line  length  (in  this 
implementation  maximum  line  length  is  80).  Figure  3.7  shows 
examples  of  bcursor. 

2 .  Ecursor 

Ecursor  is  short  for  end  cursor  position.  It  is 
the  column  position  at  which  the  right  most  character  of  a 
production  will  be  printed.  This  is  a  synthesized 
attribute  with  an  integer  value.  This  attribute  can  range 
in  value  from  one  to  the  maximum  line  length  (in  this 
implementation  line  length  is  80).  The  ecursor  of  any  rule 


is  the  bcursor  of  the  next  rule  in  the  parse  tree.  Figure 
3.7  shows  the  interplay  between  bcursor  and  ecursor. 


action_list 

EXCEPTION  parametrized_name 

{ 

parametrized_name . bcursor=action_list . bcursor+10 ( * ) ; 
action_list . ecursor  =  parametrized_name . ecursor; 

} 

message_header 

optional_exception  optional_name  formal_arguments 

{ 

optional_exception . bcursor  =  message_header . bcursor ; 
optional_name . bcursor  =  optional_exception.ecursor; 
formal_arguments . bcursor  =  optional_name. ecursor; 
message_header . ecursor  =  f ormal_arguments . ecursor; 


(*)10  is  the  number  of  characters  in  the  word 
EXCEPTION  plus  one 

Figure  3.7  Bcursor  and  Ecursor  Examples 


3 .  Padding 

Padding  is  short  for  necessary  blank  spaces  to  pad. 
It  is  a  string  of  blank  spaces  to  put  at  the  beginning  of  a 
new  line  when  the  current  line  must  be  split  because  it  is 
longer  than  the  maximum  line  length.  This  is  an  inherited 
attribute  with  a  string  value  of  blank  characters.  The 
value  of  the  attribute  can  range  from  zero  blank  characters 
to  the  maximum  line  length.  Figure  3.8  shows  an  example  of 
the  implementation  of  the  padding  attribute. 
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■ 

■ 

1 

i 

instance 

: optionally  virtual  INSTANCE  parametrized  name  =  1 

parametrized  name  comment  hide  renames  END 

C 

parametrized_name[ 1 ] .padding  = 

[ spaces ( optionally_virtual . ecursor ) , spaces ( 9 ) ] ; ( * ) 
parametrized  name[2] .padding  = 
parametrized_name[ 1 ] .padding; 
hide. padding  =  hide. indent; 
renames .padding  =  renames . indent ; 

} 

■ 

(*)spaces(9)  is  a  function  that  produces  a  string  of  nine 
blank  characters 

Figure  3.8  Padding  Example 

4 .  Indent 

Indent  is  short  for  indentation.  It  is  a  string  of 
blank  characters  associated  with  each  nonterminal  symbol  of 
the  same  production  rule.  At  each  level  of  nesting  the 
number  of  blanks  associated  with  the  value  of  the  attribute 
indent  increases  by  three.  This  is  an  inherited  attribute 
with  a  string  value.  The  string  value  for  indent  is  the 
number  of  blanks  associated  with  a  nonterminal  symbol.  The 
length  of  the  string  can  range  from  zero  to  the  maximum 
length  of  line  (in  this  case  it  also  has  to  be  a  multiple  of 
three  so  the  maximum  value  would  be  78).  This  allows  all 
related  lines  to  be  easily  seen  and  to  maintain  the 
structure  of  the  code.  Figure  3.9  shows  an  example  of  how 
the  indent  attribute  is  used. 
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function 

:  optionally_virt  interface  messages  concepts 

C 

optionally_virt . indent* [ function . indent , spaces ( 3 )  ]  ( * ) ; 
interface. indent  =  [ function. indent , spaces ( 3 )](#) ; 
messages . indent  =  [function. indent , spaces ( 3 )] ; 
concepts . indent  =  [ function. indent, spaces( 3) ] ; 

) 


(*)"["  and  "]"  are  symbols  to  represent  string 
concatenation  of  all  values  between  the  two  symbols 


(#)spaces(3)  is  a  function  producing  a  string  of  three 
blank  characters 

Figure  3.9  Indent  Example 


On  the  surface  it  appears  that  indent  and  padding 

are  very  similar  and  could  be  combined.  This  is  not  the 

|  case.  Indent  has  a  length  that  is  always  a  multiple  of 

three,  a  forced  linefeed  occurs  with  every  indent  and  indent 
is  only  used  with  keywords.  Indent  is  designed  to  show  the 

|  nesting  levels  of  all  symbols  from  the  same  production. 

Padding,  on  the  other  hand,  can  range  in  length  from  zero  to 
the  maximum  line  length,  linefeeds  are  optional  and  is  used 
i  only  to  assist  in  lines  that  are  too  long  to  fit  on  one 

line.  Padding  is  designed  to  format  long  lines  keeping  all 

text  of  the  long  line  grouped  together.  Figure  3.8  shows 
i  the  interplay  between  the  two  attributes  padding  and  indent. 


t 
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5.  Str  value 

Str_value  is  short  for  string  value.  The  output  of 
the  pretty  printer  is  the  str_value  attribute  of  the  start 
symbol  at  the  root  of  the  parse  tree.  It  is  the  set  of 
terminal  symbols  deriv<  d  from  a  production  rule  together 
with  spaces  and  linefeeds  for  formatted  output.  This  is  a 
synthesized  attribute  with  a  string  value.  The  length  of 
str_value  can  be  of  any  value  from  zero  to  infinity.  The 
str_value  of  the  start  symbol  will  have  the  longest  length. 
Concatenation  is  used  to  put  different  str_value  attributes 
together.  Figure  3.10  shows  an  example  of  the  concatenation 
of  strings  to  obtain  a  value  for  str  value. 


definition 

:  DEFINITION  interface  concepts  END  comment 

C 

definition. str_value  =  ["\n",  definition. indent , 
"DEFINITION  ",  inter f ace. str_value, 
concepts. str_value , "\n" ,  "END",  comment . str_value , 
"\n" , " \n" ] ; 

} 

Figure  3.10  Str_value  Example 


6 .  Length 

Length  is  short  for  number  of  characters  long.  It 
is  the  number  of  printable  characters  in  a  given  production 
rule.  It  is  a  synthesized  attribute  with  an  integer  value, 
which  is  used  to  determine  if  an  expression  will  fit  on  the 
remainder  of  the  current  line.  Length  is  important  because 
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it  counts  the  actual  number  of  characters  ignoring  possible 
padding,  carriage  returns,  or  line  feeds.  It  is  utilized  by 
the  expression  production  rule  and  production  rules  that 
have  comment  as  one  of  their  nonterminal  symbols.  Figure 
3.11  shows  examples  of  the  attribute  length. 


expression 

:  ' $ '  expression 

( 

expression [1 ] .length  =  1  +  expression[ 2 ]. length- 
expression^  ].  bcursor  =  expression[ 1 ] .bcursor  +1+ 

expression^ 2 ]. length  <=  80 
->  expression[ 1 ]. bcursor  +  1 
#  len(expression[ 1 ] .padding)  +  l; 


Figure  3.11  Length  Example 


D.  PRETTY  PRINTER  RULES 

The  language  dependent  pretty  printer  has  only  a  few 
general  rules  of  interest  to  the  user  of  the  pretty  printer. 
For  an  implementor  or  someone  who  wants  to  know  more  details 
about  the  pretty  printer,  the  specific  rules  define  the 
behavior  of  the  pretty  printer  in  detail. 

1 .  Rules  for  Using  the  Pretty  Printer 

There  are  several  general  rules  for  the  use  of  this 
pretty  printer.  First  the  input  must  be  syntactically 
correct.  If  it  is  not  correct  the  software  will  print  out  a 
syntax  error  message  (it  may  or  may  not  print  out  any  of  the 
input  data).  Figure  3.12  shows  an  example  of  what  happens 
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when  the  pretty  printer  is  supplied  with  syntactically 
incorrect  code. 


1:  MACHINE 

•'Syntax  error 

Note:  1  is  the  line  number  of  the  error 

*  points  to  the  point  the  syntax  error 
was  detected 

Figure  3.12  Syntactically  Incorrect  Code 
Output  Example 

Secondly,  the  input  can  come  from  either  a  file  or  can 
be  typed  from  the  terminal.  The  input  code  can  be  in  any 
format  provided  its  syntax  is  correct.  For  most 
applications  it  seems  quite  reasonable  for  the  user  to 
already  have  a  file  created.  It  is  extremely  time  consuming 
to  manually  enter  the  code  each  time,  not  to  speak  of  the 
likelihood  of  typing  mistakes  which  will  force  the  user  to 
start  over  again.  It  is  highly  recommended  that  the  input 
come  from  a  file. 

The  pretty  printer  is  invoked  in  one  of  two  ways.  The 
first  method  is  by  typing  the  file  name  of  the  compiled  Spec 
code  followed  by  a  file  name  with  a  set  of  options.  The 
possible  options  that  are  available  are  shown  in  Figure  3.13 
[Ref.  9 : pp .  23-24]. 

The  second  method  to  invoke  the  pretty  printer  is  to 
type  the  file  name  of  the  compiled  Spec  code,  a  carriage 
return  and  then  manually  enter  all  of  the  code  for  the 
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input  from  the  keyboard.  When  finished  type  "control  d"  and 
the  output  will  appear  at  the  standard  output.  Figure  3.14 
shows  an  example  of  executing  the  pretty  printer  with  both 
of  the  methods  described.  The  name  of  the  compiled  Kodiyak 
code  for  the  pretty  printer  is  stored  in  the  file  printer 
and  the  name  of  the  input  file  is  SAMPLE  (when  one  is 
specified).  An  explanation  of  the  different  commands 
invoked  follow  Figure  3.14. 


-h  Print  out  a  list  of  legal  options. 

file  Read  input  from  "file"rather  than  the  standard 
input 

-e  Continue  attribute  evaluation  even  after  an  | 

error  occurs.  This  is  useful  when  debugging 
attribute  definitions.  | 

I 

-1  Print  out  all  tokens  as  they  are  scanned. 

-y  Print  out  all  grammar  rule  reductions  as  they 

occur. 

-L  Turn  on  LEX's  debugging  features. 

-Y  Turn  on  YACC's  debugging  features. 

-c  Generate  a  core  image  when  a  run-time  error 
occurs 

-s  Print  out  storage  statistics  after  all 
attribute  evaluations  is  completed. 

-o  file  Divert  the  standard  output  to  "file". 

Figure  3.13  Printer  Options 
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A 

printer  SAMPLE 
B 

printer  SAMPLE  -o  OUTPUT 
C 

printer  -h 
D 

printer  SAMPLE  -y 
E 

printer 

Figure  3.14  Invoicing  the  Code  Example 

Part  A  invokes  the  pretty  printer  using  the  input  file 
SAMPLE  and  the  formatted  output  will  be  printed  to  the 
standard  output.  Part  B  invokes  the  pretty  printer  using 
the  input  file  SAMPLE  and  the  formatted  output  will  be  sent 
to  the  file  OUTPUT.  Part  C  invokes  the  pretty  printer  but 
in  this  case  a  list  of  the  options  that  are  available  will 
be  printed.  The  list  printed  is  similar  to  Figure  3.13. 
Part  D  invokes  the  pretty  printer  using  the  input  file 
SAMPLE  but  in  this  case  it  will  print  out  all  grammar  rule 
reductions  as  they  occur.  This  may  assist  in  diagnosing 
syntax  errors.  Part  E  invokes  the  pretty  printer  with  the 
input  coming  from  the  terminal.  The  user  must  type  in  the 
necessary  code  followed  by  a  "control  d"  to  exit.  Output 
will  go  to  the  standard  output. 
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.  Rules  for  Implementing  the  Pretty  Printer 


The  above  section  looked  at  the  general  rules  for 
the  successful  operation  of  the  pretty  printer.  Those  are 
the  only  rules  the  user  needs  to  know  to  use  the  pretty 
printer.  An  implementor  or  someone  who  may  want  to  know 
more  details  will  be  interested  in  the  specific  rules  for 
the  pretty  printer.  There  are  four  specific  implementation 
rules.  These  rules  with  their  guidelines  and  exceptions 
explain  the  complete  operation  of  this  language  dependent 
pretty  printer.  The  four  rules  that  will  be  explained  in 
detail  deal  with: 

( 1 )  Keywords 

(2)  Terminal  symbols 

( 3 )  Nonterminal  symbols 

( 4 )  Comments 

a .  Keyword  Rule 

Keywords  are  special  reserved  words  in  Spec. 
All  keywords  are  capitalized.  All  the  other  tokens  in  the 
language  can  use  uppercase  or  lowercase  letters  or  a 
combination  of  the  two,  but  all  keywords  are  distinguished 
by  the  use  of  all  uppercase  letters.  Also  as  noted  earlier 
there  are  three  types  of  keywords: 

(1)  General  keywords 

(2)  Expression  keywords 

(3)  Special  keywords 

The  rule  for  general  keywords  states  the  output 
consists  of  a  carriage  return,  line  feed,  current 
production  rule  indenting  and  then  the  keyword.  The  rule 
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for  expression  keywords  states  that  these  symbols  are  to  be 
treated  exactly  the  same  as  a  terminal  symbol.  See  the 
following  section  for  the  terminal  symbol  rule. 

All  special  keywords  appear  after  a  general 
keyword.  RENAME  always  proceeds  AS,  IF  always  proceeds  FI 
and  DO  always  proceeds  OD.  For  these  special  keywords  the 
rule  states  if  room  allows  the  special  keyword  will  appear 
on  the  same  line  as  the  general  keyword  otherwise  the 
special  keyword  will  appear  directly  beneath  the  general 
keyword  (on  the  following  line)  at  the  same  degree  of 
indentation. 

The  exceptions  to  the  above  three  rules  are  few 
but  are  extremely  important  to  the  pretty  printer.  First, 
only  the  first  general  keyword  is  effected  by  the  rule  for 
general  keywords  when  two  general  keywords  appear  one  after 
the  other.  This  saves  an  unnecessary  carriage  return  and 
line  feed.  Second,  all  three  rules  are  ignored  when  any 
type  of  a  keyword  directly  follows  a  terminal  symbol.  In 
this  case  the  rule  for  that  keyword  type  will  be  followed 
only  if  the  keyword  will  not  fit  on  the  current  line. 
Figure  3.15  summarizes  the  three  keyword  rules  and  the 
exceptions  to  these  keywords  rules, 
b.  Terminal  Rule 

A  terminal  symbol  is  defined  as  a  symbol  that 
can  appear  only  on  the  right  side  of  a  production  rule  [Ref. 
6:p.  97]  or  as  a  primitive  symbol  of  the  language  [Ref.  5:p. 
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77]  (i.e.,  cannot  be  reduced  any  further).  Keywords  by  this 
definition  are  terminals  but  in  this  implementation  keywords 
are  considered  a  separate  category  of  symbols. 


RULE  1 

The  rule  for  a  general  keyword  states  the  output 
consists  of  a  carriage  return,  a  line  feed,  an 
associated  production  rule  indentation  and  the 
keyword  (with  the  keyword  all  in  capital  letters). 

RULE  2 

Expression  keywords  are  treated  like  terminal 
symbols.  (See  terminal  symbol  rule). 

RULE  3 

All  special  keywords  follow  a  general  keyword. 

The  special  keyword  appears  on  the  same  line  as  the 
general  keyword  if  room  permits;  otherwise,  the 
special  keyword  will  appear  directly  beneath  the 
general  keyword  at  the  same  degree  of  indentation 

EXCEPTIONS 

1. 

When  two  general  keywords  appear  in  a  row  only  the 
first  general  keyword  follows  the  rule  for  general 
keywords.  This  rule  is  ignored  by  the  second  keyword.  I 

2. 

When  any  keyword  appears  after  a  terminal  symbol 
all  three  rules  are  ignored.  The  rules  are  only 
followed  if  the  keyword  will  not  fit  on  the  current 
line . 

Figure  3.15  Keyword  Rules  and  Exceptions  i 


In  this  implementation  there  are  two  types  of 
terminal  symbols.  They  are  constant  length  terminal  symbol 
(CL  terminal)  and  variable  length  terminal  symbol  (VL 
terminal).  The  CL  terminal  symbols  (those  with  symbol 
values  different  from  their  symbol  names)  are  shown  in 
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Figure  3.16  and  the  CL  terminal  symbols  (those  with  the  same 


symbol  name  and  value)  are  shown  in  Figure  3.17.  The  vl 
terminal  symbols  involve  the  use  of  the  built  in  attribute 
%text.  The  six  VL  terminal  symbols  along  with  the  way  they 
appear  in  the  language  are  shown  in  Figure  3.18. 
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Figure  3.16  CL  Terminal  Symbols 

Symbol  Values  Different  from  Symbol  Name 


The  terminal  symbol  rule  checks  for  the  end  of 
line,  when  a  terminal  symbol  (either  kind)  is  encountered 
an  end  of  line  check  is  done.  This  length  check  is  to  see 
if  the  maximum  line  length  will  be  exceeded  if  the  terminal 
symbol  is  added  to  the  str_value.  This  general  rule  for 
terminal  symbols  can  be  divided  into  two  cases  depending  on 
the  value  of  the  length  check  sum.  If  this  length  check  sum 
is  less  than  or  equal  to  the  line  length  than  the  value  of 
the  production  rule  attribute  str_value  is  the  value  of  the 


l 


| 
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terminal  symbol  (depending  on  the  terminal  symbol  it  may  be 
concatenated  with  one  blank  character).  If  the  length  check 
sum  is  greater  than  80  then  the  value  of  the  production  rule 
attribute  str_value  is  the  concatenation  of  a  carriage 
return,  line  feed,  production  rule  padding  and  the  value  of 
the  terminal  symbol  (depending  of  the  terminal  symbol  it  may 
be  concatenated  with  one  blank  character). 
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Figure  3.17  CL  Terminal 

Symbols 

Symbol  Name 

Same  as  Symbol  Value 

Terminal  Symbol  Name 

Appearance  in  Code 

NAME 

NAME . %text 

INTEGER-LITERAL 

INTEGER-LITERAL . %text 

REAL-LITERAL 

REAL-LITERAL . %text 

CHAR-LITERAL 

CHAR-LITERAL . %text 

STRING  LITERAL 

STRING-LITERAL . %text 

COMMENT 

COMMENT. %text 

Figure  3.18  VL  Terminal  Symbols 
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The  length  check  sum  is  computed  in  one  of  two 
ways  depending  upon  which  production  rule  is  being  used.  If 
the  terminal  symbol  (either  kind)  is  not  part  of  an 
expression  production  than  the  length  check  sum  is  the  sum 
of  the  current  cursor  position,  the  length  of  the  terminal 
symbol  and  one  (for  a  blank  space).  Otherwise,  if  the 
terminal  symbol  (either  kind)  is  part  of  the  expression 
production  rule  then  the  length  check  sum  includes  the  sum 
of  the  current  cursor  position,  the  length  of  the  terminal 
symbol  value,  one  (for  a  blank  character)  and  the  length  of 
the  symbol  or  symbol  to  the  right  of  the  terminal  symbol  in 
the  production  rule.  Figure  3.19  summarizes  the  general 
rule  for  the  terminal  symbols  along  with  the  rules  for 
calculating  the  length  check  sum. 

There  are  three  exceptions  to  the  terminal 
symbol  rule.  First  when  a  nonterminal  symbol  (a  symbol  that 
can  be  reduced)  precedes  a  VL  terminal  symbol  (which 
precedes  a  CL  terminal  symbol ) ,  the  length  check  sum 
includes  the  length  of  the  VL  terminal  symbol  as  well  as  the 
CL  terminal  symbol . 

The  second  exception  to  this  rule  is  when  CL 
terminal  symbols  appear  in  pairs.  The  only  CL  terminal 
symbols  this  exception  applies  to  are  the  right  and  left 
parenthesis  and  the  right  and  left  square  bracket .  The 
right  parenthesis  and  the  right  square  bracket  do  not  cause 
a  check  for  the  end  of  line. 
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The  general  rule  when  encountering  a  terminal  symbol 
(both  CL  &  VL)  is  to  do  a  check  for  the  end  of  the  line. 


LENGTH  CHECK  SUM  <=  80 

str_value  =  terminal  symbol  value  (may  have  one  blank 
character  at  end) 

LENGTH  CHECK  SUM  >  80 

str_value  =  [carriage  return,  line  feed,  production 
rule  padding,  terminal  symbol  value] 

(may  have  one  blank  character  at  end) 


TERMINAL  SYMBOL  PART  OF  EXPRESSION  PRODUCTION  RULE 
length  check  sum  =  current  cursor  position  + 

length  of  terminal  symbol  + 
(possibly  one  for  blank  space) 


TERMINAL  SYMBOL  NOT  PART  OF  EXPRESSION  PRODUCTION  RULE 
length  check  sum  =  current  cursor  position  + 

length  of  terminal  symbol  + 
length  of  rule(s)  to  the  rule  of 
the  terminal  symbol  + 

(possible  one  for  blank  space) 


Figure  3.19  Terminal  Symbol  Rule  and  Length  Check 
Sum  Calculation 


The  third  exception  occurs  when  a  comment 
immediately  precedes  a  terminal  symbol  (either  kind).  A 
check  is  first  done  to  see  if  a  comment  exists.  If  a 
comment  does  not  exist  the  general  rule  is  followed, 
otherwise  the  production  rule  str_value  includes  a  carriage 
return,  line  feed,  production  rule  padding  and  the  value  of 
the  terminal  symbol  (depending  on  the  terminal  symbol  may 
include  one  blank  character).  Figure  3.20  outlines  the 
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three  exceptions  to  the  general  rule.  Figures  3.21  and  3.22 
show  examples  of  the  terminal  symbol  rule  and  exceptions. 


1.  Nonterminal  symbol  proceeding  a  VL  terminal 

symbol  (with  the  VL  terminal  symbol  proceeding 
a  CL  terminal  symbol) 

length  check  sum  =  current  cursor  position  + 

length  of  the  VL  terminal  symbol  + 
length  of  the  CL  terminal  symbol  + 
one  (blank  between  terminal 
symbols ) 


2.  CL  terminal  symbols  appearing  in  pairs 
(applies  to  ")"  and  "]"  only) 

These  two  symbols  do  not  cause  a  end  of  line  check 


3.  Comment  immediately  precedes  a  terminal  symbol 

If  comment  does  not  exist  follow  general  rule 
else 

str_value  =  [carriage  return,  line  feed, 
production  rule  padding, 
terminal  symbol  value] 

(possibly  one  blank  character 


Figure  3.20  Terminal  Rule  Exceptions 


c.  Nonterminal  Rule 

The  rule  for  nonterminal  symbols  is  the  easiest 
of  all  the  rules.  A  nonterminal  symbol  in  a  production  rule 
will  specify  the  value  of  all  attributes  that  its  own 
production  rule  needs  and  those  values  of  the  attributes 
that  its  children's  production  rules  may  need.  Depending  on 
which  nonterminal  symbol  is  involved  any  or  all  of  the  six 
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A.  Length  check  with  expression  production 

expression 

:  NOT  expression 

C 

expression^ ]  .str_value  =  expression[  1  ] . bcursor  + 

1  +  expression[ 2 ] .length  <=  80 
_>  expression[ 2 ] . str  value] 

#  [ "\n" ,expression[l ] .padding, , 

expression[ 2 ] . str_value] ; 

} 

B.  Length  check  without  expression  production 
field_list 

:  field_list  ' , '  field  j 

{  I 

field  list[l] .str_value  =  I 

field_list [2] .ecursor  +  2  <=  80  j 

->  [field_list[2] . str_value, " ,  ",  field . str_value] 

#  [field_list[2] .str  value,",  ",  "\n",  ; 

field_list [ 1 ] . padding, field .str_value] ; 

} 

C.  Length  check  with  first  exception 
expression 

:  expression  ' . 1  NAME 

{  ! 

expression[ 1 ] . str_value  =  expression[ 2 ]. ecursor  +| 
1  +  len(NAME%text )  <=80  I 

->  [expression[ 2 ] .str_value,  " . " , NAME . % tex t ] 

#  [expression[2] .str  value,  ,"\n", 
expression [ 1 ] .padding, NAME. %text] ; 

) 


Figure  3.21  Terminal  Symbol  Examples 


A.  Length  check  w'th  second  exception 


actual_parameters 

:  ' ( '  arg_list  ' ) ' 

{ 

actual_parameters . str_value  = 

actual_parameters . bcursor  +  1  <  80 
->  arg_list . str_value, " ) " ] 

#  [ "\n" , actual_parameters .padding, 

arg_list . str_value 

} 

B.  Comment  before  terminal  symbol 
concept 

CONCEPT  formal_pa  ' : '  type_spec 

{ 

concept. str  value  =  formal jpa.ecursor  <  0* 

->  [ "\n" , "\n" , concept. indent, concept, 

formal_pa.str_value, ”\n" ,forma_pa. padding, 
" :  " , type_spec . str_value ] 

#  formal_pa.ecursor  +  2  <=  80 

- >  [ " \n" , " \n" , concept . indent , CONCEPT , 

formal_pa.str_value, " :  ", 
type_spec . str_value ] 

#  [ " \n" , " \n" , concept . indent , CONCEPT , 

formal_pa . str_value , "\n" , forma_pa .padding, 
" :  " , type_spec . str_value ] ; 

} 


Figure  3.22  Terminal  Symbol  Examples 


61 


attributes  that  this  implementation  uses  can  be  specified. 
Not  all  of  the  nonterminal  symbols  use  all  of  the  six 
attributes.  Figure  3.23  shows  some  examples  of  how 

attributes  are  used  with  the  nonterminal  symbols .  In  the 
first  example  in  Figure  3.23  the  nonterminal  symbol 
"name_list"  only  needs  two  attributes  and  "comment"  needs 
only  one  attribute.  In  the  second  example  in  Figure  3.23 
the  nonterminal  symbol  "interface"  does  not  need  or  use  the 
attribute  indent  but  the  nonterminals  "imports",  "inherits" 
and  "export"  need  indent  therefore  the  parent  is  passing 
along  its  value  of  indent  to  its  children, 
d .  Comment  Rule 

The  rule  for  a  comment  concern  where  a  comment 
can  and  cannot  be  placed.  This  rule  is  language  dependent. 
In  Spec  comments  can  occur  after  any  nonterminal  symbol  but 
comments  cannot  occur  immediately  after  any  terminal  symbol. 
See  Figures  3.16,  3.17  and  3.18  for  the  list  of  CL  terminal 
symbols  and  values  and  VL  terminal  symbols.  There  are  two 
exceptions  to  this  rule.  First,  a  comment  can  occur  after 
the  CL  terminal  symbol  that  comes  as  the  second  in  a  pair 
(i.e.,  ")"  and  "]"  )  when  the  production  rule  that  involves 
the  CL  terminal  symbol  does  not  have  a  nonterminal  symbol 
immediately  following  the  CL  terminal  symbol.  Second,  a 
comment  cannot  occur  immediately  after  a  keyword.  Figure 
3.24  summarizes  the  comment  rule  and  its  two  exceptions. 
Note  this  is  strictly  dependent  on  the  language  implemented. 
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A  nonterminal  symbol  will  specify  the  value  of  all 
attributes  that  its  own  production  rule  needs  and 
those  attributes  that  any  of  its  children  may  need. 

EXAMPLE  ONE 

hide 

:  HIDE  name_list  comment 

( 

name_list . bcursor  =  hide.bcursor  +  5; 
name_list .padding  =  [hide. padding,  spaces (5); 
comment . bcursor  =  name_list .ecursor; 
hide. str_value  =  [ "\n" , hide. indent , "HIDE  ", 

name_list . str_value , 
comment . str_value ] ; 

} 

EXAMPLE  TWO 
interface 

:  NAME  inherits  imports  export  comment 

( 

inherits . indent  =  [interface. indent,  spaces ( 3 )] ; 
export . indent  =  [ interface . indent ,  spaces(3)]; 
imports . indent  =  [ interface . indent ,  spaces(3)]; 
interface. str_value  =  [NAME. %text , 

inherits . str_value, 
imports . str_value , 
export . str_value , 
comment . str_value ] ; 

} 


Figure  3.23  Nonterminal  Rule  and  Examples 


A  comment  can  occur  after  any  nonterminal  symbol  but 
cannot  occur  immediately  after  any  terminal  symbol 
(either  kind). 

EXCEPTIONS 

A.  A  comment  can  occur  after  the  CL 

terminal  symbol  ")"  or  "]"  if  the  production  rule 
does  not  have  a  nonterminal  symbol  immediately 
following  either  of  these  CL  terminal  symbols. 


B.  A  comment  cannot  occur  immediately  after  any 
keyword . 

Figure  3.24  Comment  Rule 
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IV.  CONCLUSIONS 


The  conclusions  of  this  thesis  address  the  issues  of 
the  specific  implementation  of  one  language  dependent 
pretty  printer  and  how  this  can  be  extended  to  generate  a 
general  purpose  language  independent  pretty  printer.  what 
was  learned  through  the  development,  design  and 
implementation  of  this  pretty  printer  can  be  abstracted, 
generalized  and  expanded  to  create  a  language  independent 
pretty  printer. 

A.  IMPACT  OF  DESIGN  DECISIONS 

The  major  impact  on  any  and  all  of  the  design  decisions 
relates  to  readability,  understandability ,  portability  and 
ease  in  modifying.  Can  what  was  done  for  a  single 
implementation  be  of  any  great  value?  The  answer  to  this 
question  is  yes.  Can  all  the  rules  and  exceptions  be 
abstracted  and  extrapolated?  The  issues  surrounding  the 
design  decisions  made  in  this  particular  implementation  and 
the  ability  to  extend  what  was  learned  center  around  four 
key  ideas.  These  four  key  ideas  are: 

(1)  Global  parameters 

(2)  Attributes 

(3)  Standardization 

( 4 )  Comments 
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1 .  Global  Parameters 

In  the  normal  sense  of  global  parameters,  such  as 
in  a  Pascal  program,  this  implementation  does  not  have  any 
global  parameters.  There  is  no  method  available  to  declare 
a  global  parameter  at  the  beginning  of  the  program  due  to 
the  tree  like  structure  that  is  used  in  parsing  and 
evaluating  the  pretty  printer.  On  the  other  hand  this 
implementation  does  have  "global  parameters"  to  a  limited 
degree.  The  line  length  and  therefore  the  right-hand  margin 
is  set  on  80.  Any  reference  to  the  right-hand  margin  is 
made  in  reference  to  this  global  parameter.  One  global 
change  to  the  value  80  (with  an  editor)  can  globally  change 
the  width  of  the  print  out  and  thereby  changing  the  value  of 
the  right-hand  margin. 

The  global  indentation  change  can  also  be  easily  made. 
SPACES ( 3 )  is  used  throughout  to  handle  the  indentation.  If 
the  indentation  width  was  changed  to  four,  for  instance,  one 
simple  global  change  with  an  editor  could  change  all 
SPACES ( 3 )  to  SPACES ( 4 ) . 

The  use  of  global  parameters  as  explained  above 
increases  the  portability  of  the  code.  Additionally,  it 
increases  the  adaptability  and  ease  of  modification  of  this 
language  dependent  pretty  printer  to  different  users 
preferences  and  desires.  The  pretty  printer  code  can  also 
be  modified  to  accept  variable  parameter  values  from  the 
command  line  if  the  computer  system  utilized  supports  that 
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feature  (i.e.,  printer  -1  80,  printer  -s  4).  In  this  case 

Kodiyak  would  have  to  be  modified  to  support  the  option  of 
command  line  inputs . 

2 .  Attributes 

There  are  only  a  small  number  of  attributes.  These 
six  attributes  are: 

(1)  Bcursor 

(2)  Ecursor 

(3)  Padding 

(4)  Indent 

(5)  Str_value 

( 6 )  Length 

Each  attribute  is  unique  and  handles  one  specific 
well  defined  function.  If  one  attribute  (or  the  concept 
behind  it)  is  changed  or  altered  the  other  attributes  will 
not  be  affected.  This  is  true  for  all  except  bcursor  and 
ecursor.  These  two  attributes  go  hand  in  hand  and  changing 
one  will  greatly  affect  the  other. 

3 .  Standards 

There  is  standardization  of  the  implementation 
throughout  the  entire  code  for  the  pretty  printer.  With  a 
given  number  of  general  rules  and  a  few  exceptions  the 
implementation  follows  a  fairly  standard  organization  (i.e., 
each  production  rule  is  basically  implemented  in  the  same 
way).  With  standardization  of  rules  generic  rules  can 
easily  be  derived  from  the  specific  rules. 

In  addition  to  standardization  in  the  pretty 
printer  code,  there  are  also  standards  in  computer  science 
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that  are  adopted  by  the  implementation.  This  includes  the 
rule  of  thumb  standard  for  the  length  of  the  standard 
indentation  unit. 

4.  Comments 

Allowing  for  freedom  of  style  in  comments  allows 
comments  to  be  almost  any  place  within  the  code.  Comments 
add  tremendously  to  the  overall  readability  of  program  code. 
The  implementation  allows  for  the  widest  variety  of  comments 
within  reason.  Within  reason  means  that  there  are  times 
when  you  do  not  want  a  comment.  As  an  example  a  comment  is 
not  a  good  idea  in  the  middle  of  a  mathematical  expression. 

B.  EVALUATION  OF  THE  PRETTY  PRINTER 

The  qualities  of  the  pretty  printer  deal  with  the 
software,  documentation  and  devices  used  in  the  actual 
development  and  execution  of  the  pretty  printer.  The 
qualities  to  be  concerned  with  center  around  the  following 
three  categories: 

(1)  Kodiyak  compiler 

(2)  Syntax  errors 

(3)  Software  extensions 

1 .  Kodiyak  Compiler 

The  Kodiyak  compiler  is  a  complex  piece  of  software 
but  when  modifications  were  made  there  was  no  apparent 
change  in  the  efficiency  and  no  slow  down  in  the  processing 
time.  To  make  a  change  to  the  compiler  one  of  its  many 
related  files  (as  shown  in  Figure  4.1)  was  modified  and  then 
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f  the  compiler  was  recompiled.  Recompiling  is  a  small 

t  sacrifice  when  making  changes  to  an  extremely  complicated 

N  piece  of  software. 


PURPOSE 


helper  functions  for  the 
Kodiyak  compiler 
Unix  Programmer's  Manual 
software  driver 

library  functions  and  C  definitions 

main  routine  for  Kodiyak  programs 

Kodiyak  translator 

Kodiyak  translator 

executes  the  translator 

macros 


Figure  4.1  Kodiyak  Files 


With  everything  that  is  good  there  are  also  some 


r 

■ 


NAME 

locallib. c 

man. entry 
k 

kclib.c 
kmain.c 
kodiyak. k 
kodiyak .m4 
kscript 
mac.m4 


drawbacks.  Changes  to  the  compiler  are  easy  to  make,  but 
sometimes  it  requires  a  change  to  the  Kodiyak  code  with  an 
associated  recompiling  of  that  code  and  other  times  the 
change  requires  a  modification  to  the  file  that  controls  the 
overall  execution  of  the  Kodiyak  compiler  (file  named  k). 
Figure  4.2  shows  some  examples  of  these  situations  with  the 
resulting  actions  needed  to  correct  the  problems. 

Another  area  of  concern  with  the  Kodiyak  compiler 
is  the  error  messages  generated.  Understandably  the  Kodiyak 
code  and  documentation  was  written  by  one  person  within  a 
six  month  time  frame.  Even  so  the  error  messages  generated 
are  hard  to  understand  and  even  harder  to  correct.  There  is 
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a  lack  of  standardization  when  an  error  had  to  be  corrected. 
The  user  has  to  search  through  the  multiple  related  files 
(those  listed  in  Figure  4.1)  to  find  the  solution  to  a  given 
error.  Once  the  correction  to  the  error  has  been  found  the 
most  obvious  correction  may  not  fix  the  problem. 


1.  Table  overflow 

Change  the  size  of  the  table  in  file  k 

2.  Memory  overflow 

Change  the  value  of  associated  variable  in 

file  kclib.c  j 

Figure  4.2  Compiler  Change  Examples  j 

As  an  example  consider  the  following.  An  error 

appeared  that  stated  "OUT  OF  XNODESPACE".  The  solution  was 

found  in  file  kclib.c.  The  documentation  [Ref.  11]  stated: 

"The  following  definitions  may  be  over-ridden  from  the  C 
compiler's  command  line.  This  allows  users  to  increase  or 
decrease  the  space  allocated  to  each  data  type  according 
to  his  needs.  cc  -DXPAIRSPACE=50000  agprog.c  -o  agprog 
would  give  the  user's  program  50,000  pairs  to  use  instead 
to  the  20,000  allocated  by  default." 

This  feature  did  not  work  as  advertised.  After 
trial  and  error  the  solution  found  involved  changing  the 
value  of  XNODESPACE  in  two  separate  locations  in  the  file 
kclib.c  and  then  recompiling  the  Kodiyak  compiler.  That 
solution  was  not  written  anywhere  or  even  suggested. 

2 .  Syntax  Errors 

Syntax  errors  are  concerned  with  the  errors  in  the 
syntax  of  the  input  code.  These  syntax  errors  can  basically 


be  of  two  types.  There  are  errors  caused  by  typing  mistakes 
and  errors  concerned  with  missing  grammar  rule(s)  in  the 
language.  These  syntax  errors  can  be  either  easy  or  hard  to 
find . 

When  the  Kodiyak  compiler  finds  any  type  of  error 
it  doesn't  guess  what  the  user  meant.  It  crashes  and  prints 
an  error  message.  The  difficulty  involves  tracking  down  the 
actual  error.  Figure  4.3  shows  examples  of  typical  error 
messages . 

1.  Spelling  or  typing  error 

1 :  MESAGE 

"Syntax  error 

2.  Grammar  rule  missing/input  does  not  match  grammar 

3:  MESSAGE  FUNCTION 

"Syntax  error 

Figure  4.3  Typical  Error  Messages 

As  Figure  4.3  shows  the  error  messages  can  be  quite 
cryptic.  In  all  cases  the  error  occurs  somewhere  after  the 
place  that  the  syntax  error  pointer  points.  The  error  in 
fact  may  be  a  several  lines  further  down  in  the  code  because 
the  language  is  parsed  in  a  tree  like  structure.  The  error 
message  pointer  points  to  the  production  rule  that  the 
pretty  printer  code  was  parsing  at  the  time  the  error 
occurred  (the  actual  error  can  be  a  descendant  of  the 
production  rule). 
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3 .  Software  Extensions 

Software  extensions  are  concerned  with  adding 
software  to  the  actual  Kodiyak  software.  The  Kodiyak 
software  is  quite  adaptable  and  has  allowed  for  user  defined 
functions  and  applications  to  be  added  to  the  existing 
software.  The  only  drawback  to  this  is  that  the  user 
defined  software  must  be  added  to  the  end  of  an  already 
existing  set  of  library  functions.  Through  experience  it 
has  been  determined  that  if  the  user-defined  functions  are 
written  in  a  separate  file  and  declared  in  an  option  added 
to  the  file  k  (that  directs  the  Kodiyak)  incompatibility 
error  messages  will  appear.  If  the  same  code  is  placed  at 
the  end  of  the  file  kclib.c  the  Kodiyak  has  no  problems  with 
the  user  defined  functions  and  everything  runs  smoothly. 

One  additional  note  about  the  user  defined 
functions.  This  allows  the  user  to  write  any  type  of 
function  that  is  desired  as  long  as  it  is  written  is  C. 
with  this  implementation  a  new  function  (named  SPACES)  was 
created  to  change  an  integer  into  the  corresponding  number 
of  blank  characters.  Writing  a  fairly  efficient  small  loop 
function  seemed  quite  easy  until  the  code  was  compiled. 
Then  the  problem  of  incompatibility  arose  between  the 
existing  code  and  the  new  function  written  in  C.  To  solve 
this  compatibility  problem  an  inefficient  function  was 
written  to  handle  the  conversion  of  integers  zero  through  80 
to  a  corresponding  string  of  blank  characters.  If  the  line 


i 

length  is  increased  above  80  the  function  SPACES  will  have 
to  modified  to  handle  all  integer  values  greater  than  80. 

i 

C.  ANALYSIS  OF  CODE 

The  analysis  of  the  pretty  printer  code  has  to  look  at 
three  general  areas.  These  three  areas  are:  j 

(1)  Efficiency  of  the  code 

(2)  Readability/understandability  of  the  code 

(3)  Ease  of  modification 

1 .  Efficiency  I 

The  efficiency  of  the  pretty  printer  must  not  only 
look  at  the  pretty  printer  code  but  also  the  Kodiyak 
compiler.  The  Kodiyak  compiler  was  not  written  to  be  I 

optimized.  With  the  limited  time  that  was  used  to  design 
and  write  the  code  it  is  really  amazing  that  it  is  as  fast 
as  it  is.  Figure  4.4  shows  some  statistics  for  file  length  ( 

compared  with  time  to  format  and  print  the  reformatted  file. 


I 


I 

The  time  should  be  considered  in  relative  terms  and 

not  absolute  values  ■ 

Figure  4.4  Pretty  Printer  Statistics 


TIME  (seconds) 


1 . 4 
2.2 
5.3 
8.8 
18.1 

32.7 

46.8 
62.0 


FILE  LENGTH  (bytes 

70 

151 

457 

819 

1594 

2706 

4275 

5428 
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Along  the  same  lines  the  pretty  printer  was  not 
written  in  any  optimized  form.  The  function  SPACES  is  not 
efficiently  coded.  It  is  efficient  in  time  but  not  in 
space.  The  most  important  point  is  that  although  it  may  not 
be  efficient  it  works.  Figure  4.5  shows  a  segment  of  the 
SPACES  function.  If  efficiency  is  an  important  issue  this 
function  can  be  modified  to  improve  its  efficiency.  Also, 
as  stated  earlier,  if  the  line  length  is  increased  this 
function  will  also  have  to  be  modified. 


xstring  vspaces  (lenstr) 
int  lenstr; 

C 

int  x; 

x  =  lenstr; 

switch(x) 

C 

case  0  :  return  (xstring) 
break ; 

case  1  :  return  (xstring)  "  "; 
break; 

case  2  :  return  (xstring)  "  " 

break; 

case  3  :  return  (xstring)  " 
break; 


} 


default  :  return  (xstring)  "" 
break ; 


Figure  4.5  Spaces 
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2 .  Readability 

Readability  is  concerned  with  the  user  being  able 
to  read  the  code  for  the  pretty  printer  and  without  too  much 
effort  understand  exactly  what  is  going  on.  Increasing  the 
code's  readability  is  the  fact  that  there  are  only  six 
attributes  each  with  a  unique  function  that  does  not  change. 
Additionally,  standard  rules  are  followed  and  there  is  a 
standardization  among  the  implementation  of  the  production 
rules.  This  basically  says  if  the  user  can  understand  one 
production  rule  he  can  probably  understand  the  majority  of 
them.  There  are  a  few  special  rules  (and  some  exceptions) 
that  may  take  the  user  a  little  longer  to  understand  but 
overall  the  pretty  printer  is  fairly  straight  forward. 

Since  it  has  few  attributes  and  only  uses  simple 
mathematics  and  string  concatenation  the  code  is  fairly 
simple.  Probably  the  most  complex  notation  used  involves 
the  if-then-else  and  if-then-else_if  evaluation  rules.  The 
syntax  for  these  constructs  are  a  little  different  but  after 
reading  through  a  few  of  them  they  become  straightforward 
(Figure  2.8  explains  the  syntax). 

Since  there  is  standardization  and  limited 
complexity  it  would  appear  that  the  pretty  printer  code 
should  be  fairly  easy  to  read  and  understand.  One  drawback 
is  by  increasing  readability  some  efficiency  has  been  lost. 
Since  this  is  a  research  project  readability  and 
understandability  of  the  Kodiyak  compiler  and  the  pretty 
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printer  are  more  important  than  optimization.  Increasing 
optimization  often  decreases  the  readability  of  any  code. 
The  pretty  printer  code  is  fairly  straight  forward  and  very 
readable . 

3.  Ease  of  Modification 

For  any  number  of  reasons  the  existing  code  may  be 
changed.  Is  this  change  an  easy  and  uncomplicated 
undertaking  and/or  is  it  going  to  be  time  consuming?  The 
pretty  printer  code  consists  of  six  attributes  and  simple 
mathematics.  Each  attribute  is  unique  and  its  function  or 
value  does  not  affect  other  attributes  (except  bcursor  and 
ecursor  which  depend  on  each  other).  Therefore  changing  the 
meaning  of  one  attribute  should  be  straight  forward  and  easy 
to  implement.  To  add  an  additional  attribute  (similar  to 
the  type  already  implemented)  will  be  time  consuming  (typing 
time)  but  fairly  simple.  On  the  other  hand  to  add  an 
attribute  that  uses  higher  order  functions  or  depends  on  the 
value  of  existing  attribute  values  will  be  time  consuming 
and  complex  (each  production  rule  will  have  to  be  looked  at 
individually). 

From  experience  the  effort  in  making  changes  is 
time  consuming  but  not  very  complicated.  As  an  example,  a 
modification  was  made  in  the  implementation  of  the 
production  rules  (and  the  children  of  the  production  rules) 
using  the  symbol  "expression".  Prior  to  the  change  the  end 
of  line  check  did  not  include  the  use  of  the  length 
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attribute.  This  length  attribute  was  added  to  all 
production  rules  very  easily.  It  was  time  consuming  because 
of  the  major  edit  to  the  pretty  printer  code  and  the  need  to 
verify  all  corrections/additions  were  made.  The  change 
itself  was  a  very  simple  modification. 

D.  APPLICATION  EXTENSION 

It  is  highly  desirable  to  apply  the  techniques  used  in 
this  implementation  to  the  development  of  a  language 
independent  pretty  printer.  Before  a  generalization  can  be 
reached  a  careful  analysis  of  the  existing  code  must  be 
completed . 

1 .  Pretty  Printer  Code  Analysis 

Chapter  three  covers  the  exact  design  and 
implementation  in  detail.  Specifically  four  general  rules 
for  this  pretty  printer  are  explained  along  with  all 
exceptions  to  each  of  the  four  general  rules.  This  section 
looks  at  the  overall  development  of  these  rules  and 
generalizes  the  method  used  to  apply  to  any  language. 

Examination  of  the  pretty  printer  production  rules, 
looking  at  how  each  production  rule  symbol  is  implemented, 
leads  to  a  list  of  generalized  symbol  categories.  Each  SPEC 
language  symbol  uniquely  fits  into  one  of  these  four 
categories  (as  listed  in  Figure  4.6). 


An  analysis  of  the  production  rules  of  SPEC 
provides  the  insight  into  the  development  of  the  four 


generalized  symbol  categories  listed  in  Figure  4.6.  Look  at 
the  production  rules  as  collections  of  symbol  categories 
instead  of  individual  rules.  In  other  words  look  at  the 
production  rules  as  combinations  of  keywords  (all  three 
types),  terminals  (CL  and  VL)  and  nonterminals.  In  this 
way  generalizations  can  be  reached.  Keywords  (general, 
expression  and  special)  are  listed  in  Figures  3.3,  3.4  and 
3.5.  All  the  terminal  symbols  of  the  language  are  listed  in 
Figures  3.16,  3.17  and  3.18.  Review  of  these  figures  and 
the  pretty  printer  code  leads  to  the  development  of  the 
general  symbol  categories  for  the  production  rules.  Figure 
4.7  lists  the  production  rules  from  the  SPEC  grammar 
transposed  into  standard  forms  using  these  symbol 
categories.  Note  that  Figure  4.7  contains  keywords  (all 
three  types  grouped  under  one  heading) ,  CL  and  VL  terminal 
symbols  and  nonterminals . 


1 .  Keyword 

2.  Terminal 

3 .  Comment 

4.  Nonterminal  i 

Figure  4.6  General  Symbol  Categories 

By  referring  back  to  the  implementation  rules  for 
the  pretty  printer  (Figures  3.15,  3.19,  3.20,  3.23  and 
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1 .  KEYWORD 

2.  CL-terminal 

3.  VL-terminal 

4.  nonterminal ( s ) 

5.  CL-terminal  VL-terminal 

6.  CL-terminal  nonterminal ( s ) 

7.  nonterminal ( s )  VL-terminal 

8.  VL-terminal  nonterminal ( s ) 

9.  KEYWORD  nonterminal ( s ) 

10.  KEYWORD  nonterminal (s)  KEYWORD 
nonterminal ( s )  CL-terminal  VL-terminal 

1 1 .  nonterminal ( s )  KEYWORD  nonterminal ( s ) 

12.  KEYWORD  VL-terminal  nonterminal ( s ) 

13.  VL-terminal  CL-terminal  nonterminal ( s ) 

14.  CL-terminal  nonterminal ( s )  CL-terminal (* ) 

15.  nonterminal ( s )  CL-terminal  nonterminal ( s ) 

16.  CL-terminal  VL-terminal  CL-terminal  nonterminal ( s ) 

17.  CL-terminal  nonterminal ( s )  CL-terminal 

nonterminal ( s ) ( * ) 

18.  KEYWORD  nonterminal ( s )  KEYWORD  nonterminal ( s ) 

19.  KEYWORD  nonterminal ( s )  CL-terminal  nonterminal ( s ) 

20.  nonterminal ( s )  CL-terminal  nonterminal ( s ) 

CL-terminal ( * ) 

21.  nonterminal(s)  CL-terminal  nonterminal ( s ) 

CL-terminal  nonterminal ( s )  CL-terminal (* ) 

22.  KEYWORD  VL-terminal  nonterminal ( s )  CL-terminal 

nonterminal (s) 

23.  KEYWORD  VL-terminal  nonterminal ( s )  KEYWORD 

nonterminal ( s ) 

24.  CL-terminal  nonterminal ( s )  CL-terminal  nonterminal ( s ) 

CL-terminal ( * ) 

25.  KEYWORD  CL-terminal  nonterminal ( s )  CL-terminal 

nonterminal ( s )  (*) 

26.  nonterminal ( s )  KEYWORD  nonterminal ( s )  KEYWORD 

nonterminal ( s ) 

27.  nonterminal(s)  KEYWORD  VL-terminal  KEYWORD 

VL-terminal  nonterminal ( s ) 

28.  KEYWORD  nonterminal ( s )  KEYWORD  nonterminals ( s ) 

KEYWORD  nonterminal ( s )  KEYWORD 

29.  nonterminal ( s )  KEYWORD  nonterminal { s )  CL-terminal 

nonterminal ( s )  KEYWORD  nonterminal ( s ) 


(*) VL-terminal  symbols  are  matched  pairs  (i.e.,  (,),[,]  )  , 
Figure  4.7  Standard  Forms 


79 


3.24)  more  generalizations  can  be  made.  VL-terminal  and 
CL-terminal  are  implemented  exactly  the  same  way.  The 
distinction  between  the  two  symbols  exists  in  the 
exceptions  to  the  terminal  symbol  rule.  Therefore  CL- 
terminal  and  VL-terminal  symbols  can  be  combined  into  the 
category  terminal.  Figure  4.7  grouped  the  symbol  comment  as 
a  nonterminal.  Because  comment  is  implemented  differently 
than  a  nonterminal,  comment  needs  to  be  in  a  separate 
category.  None  of  the  remaining  symbols  can  be  combined. 
This  leads  to  the  modification  of  the  standard  forms  into  a 
new  list  of  standard  forms  as  listed  in  Figures  4.8  and  4.9. 
It  can  be  concluded  that  each  production  rule  is  a 
combination  of  one  or  more  of  the  four  general  symbol 
categories  (listed  in  Figure  4.6)  repeated  one  or  more 
times . 

2 .  Language  Independent  Pretty  Printer 

The  approach  used  in  this  particular  implementation 
is  very  regular  and  could  be  applied  mechanically  by  a 
preprocessor.  All  the  information  that  the  preprocessor 
obtained  would  be  translated  and  sent  to  the  Kodiyak 
compiler.  The  preprocessor  is  responsible  for  the  language 
dependent  questions  as  well  as  any  special  features  the  user 
wanted  considered  for  their  particular  implementation. 
Language  dependent  questions  include  such  items  as  file  name 
containing  the  grammar  of  the  language  to  be  pretty 
printed,  keyword  specifications,  terminal  symbols  and 
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1 .  KEYWORD 

2.  terminal (s) 

3.  nonterminal ( s ) 

4.  nonterminal ( s )  terminal(s) 

5.  terminal(s)  nonterminal ( s ) 

6.  KEYWORD  nonterminal ( s ) 

7.  KEYWORD  nonterminal { s )  KEYWORD 

8.  nonterminal (s)  KEYWORD  nonterminal ( s ) 

9 .  KEYWORD  terminal  nonterminal ( s ) 

10.  terminal  nonterminal ( s )  terminal (*) 

11.  nonterminal (s)  terminal  nonterminal ( s ) 

12.  terminal  nonterminal ( s )  terminal  nonterminal ( s )  (*) 

13.  nonterminal  terminal  nonterminal ( s )  terminal  (*) 

14.  KEYWORD  terminal  nonterminal ( s )  KEYWORD 

nonterminal ( s ) 

15.  nonterminal* s)  KEYWORD  nonterminal ( s )  KEYWORD 

nonterminal ( s ) 

16.  nonterminal ( s )  terminal  nonterminal ( s ) 

terminal  nonterminal  terminal**) 

17.  KEYWORD  nonterminal ( s )  KEYWORD  nonterminals ( s ) 

KEYWORD  nonterminal (s)  KEYWORD 


(*) terminal  symbols  are  matched  pairs  (i.e.,  (,),[,]) 

Figure  4.8  Standard  Forms  Revised 
Without  Comment  Symbol 
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1 .  nonterminal { s )  comment 

2 .  comment  nonterminal ( s ) 

3.  terminal(s)  nonterminal ( s )  comment 

4 .  KEYWORD  nonterminal ( s )  comment 

5.  terminal  nonterminal ( s )  terminal  comment (*) 

6.  KEYWORD  nonterminal ( s )  KEYWORD  comment 

7.  nonterminal (s)  terminal  comment  nonterminal 

8.  KEYWORD  nonterminal ( s )  comment  nonterminal ( s ) 

9.  nonterminal ( s )  terminal  comment  nonterminal ( s ) 

comment 

10.  KEYWORD  terminal  nonterminal ( s )  terminal  comment  (*) 

11.  KEYWORD  nonterminal  comment  nonterminal ( s )  comment 

12.  nonterminal ( s )  KEYWORD  nonterminal ( s )  KEYWORD  comment 

13.  nonterminal ( s )  KEYWORD  nonterminal  comment 

nonterminal ( s )  comment 

14.  KEYWORD  nonterminal  KEYWORD  nonterminal  comment 

nonterminal ( s ) 

15.  nonterminal  KEYWORD  terminal  KEYWORD 

terminal  comment 

16.  keyword  nonterminal ( s )  terminal  nonterminal 

comment  nonterminal 

17.  terminal  nonterminal ( s )  terminal  comment 

nonterminal(s)  terminal(*) 

18.  KEYWORD  terminal  nonterminal ( s )  terminal 

nonterminal  comment  terminal  (*) 

19.  nonterminal  KEYWORD  nonterminal { s )  comment  KEYWORD 

nonterminal  comment 

20.  nonterminal ( s )  KEYWORD  nonterminal ( s )  terminal 

nonterminal ( s )  comment  nonterminal ( s ) 

KEYWORD  comment 

(*) terminal  symbols  are  matched  pairs  (i.e.,  (,),[,]  ) 


Figure  4.9  Standard  Forms  Revised 
with  Comment  Symbol 
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values,  keyword  types,  paired  terminal  symbols,  comment 
symbol,  etc.  The  grammar  file  should  be  formatted  as 
specified  by  the  Kodiyak  manual  [Ref.  9:pp.  2-25].  Special 
features  would  include  such  things  as  the  standard 
indentation,  width  of  the  paper,  unusual  lengths  of  tokens, 
left-hand  margin  to  start  at  a  value  other  than  one, 
special  handling  for  a  grammar  rule,  etc. 

Figure  4.10  shows  how  the  preprocessor  works.  The 
preprocessor  could  be  either  menu  driven  (asking  a  series  of 
questions)  or  a  command  line  format  could  be  used  (i.e.,  pp 
grammarfilename  -w  120  where  pp  invokes  the  preprocessor, 
grammarf ilename  is  the  name  of  the  file  containing  the 
grammar  and  -w  120  states  the  line  length  is  120 
characters).  This  method  for  invoking  the  preprocessor 
would  be  system  dependent.  The  preprocessor  would  take  in 
all  necessary  data,  use  a  set  of  production  rule  and 
generate  an  attribute  grammar,  format  the  attribute  grammar 
to  be  compatible  with  the  Kodiyak  compiler  and  transmit  its 
data  to  the  Kodiyak  compiler  which  in  turn  would  produce  a 
working  pretty  printer  for  the  desired  language. 

The  rules  used  by  the  preprocessor  to  generate  the 
attribute  grammar  to  be  used  by  the  Kodiyak  compiler  in 
generating  the  language  independent  pretty  printer  are  very 
straight  forward.  Figure  4.11  shows  the  four  rules  needed 
to  implement  a  language  independent  pretty  printer. 
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User 

Input 


PREPROCESSOR 


attribute  grammar 
for  pretty  printer 


KODIYAK  COMPILER  - — , 


working  ! 
pretty  printer  |  | 

Figure  4.10  Preprocessor 

Each  production  rule,  for  the  given  grammar,  must 
be  transformed  into  a  set  of  attribute  equations  to  produce 
the  desired  pretty  printer  code.  The  four  language 
independent  rules  listed  in  Figure  4.11  use  the  same 
attributes  used  in  the  language  dependent  pretty  printer 
implementation.  Each  symbol  in  a  production  rule  must  be 
categorized  and  then  the  associated  rule  for  that  symbol 
must  be  applied. 

As  an  example  consider  the  production  rule  "X  :  A  B 
C  D".  The  preprocessor  first  would  determine  the  category 
for  each  of  the  four  symbols  in  this  production  rule.  Next 


1 .  X  :  Keyword 

X.str_value  =  if  standard 

then  [ "\n" , indent , keyword ] 
else  if  keyword  fits  on  current  line 
then  [keyword] 
else  [ "\n" , indent, keyword] 
X.ecursor  =  if  standard 

then  len( indent)  +  len( Keyword) 
else  if  keyword  fits  on  current  line 
then  X.bcursor  +  len( keyword) 

else  len( indent)  +  len( keyword) 

2.  X  :  Nonterminal 

Nonterminal . bcursor  =  if  (X.bcursor  <  0) 

then  len( padding) 
else  X.bcursor 

X.ecursor  =  Nonterminal . ecursor 
Nonterminal. padding  =  x. padding 
Nonterminal . indent  =  [X. indent,  spaces(3)] 
X.str_value  =  if  (X.bcursor  <  0) 

then  [padding, nonterminal . str_value 
else  nonterminal . str_value 

X  :  Terminal 

X.str_value  =  if  (X.bcursor  +  len ( terminal ) )  <  END 

then  terminal 

else  [ "\n" , padding, terminal] 
X.ecursor  *  if  (X.bcursor  +  len ( terminal ) )  <  END 
then  X.bcursor  +  len( terminal ) 
else  len(padding)  +  len(terminal ) 

*  if  paired  terminal  symbol  check  for  <=  END 

END  =  MAXIMUM  LINE  LENGTH 

X  :  Comment 

X.str_value  =  Comment . str_value 
X.ecursor  =  if  len ( Comment . str_value  )  >  0 
then  -1  (*comment  exists*) 
else  +1 


Figure  4.11  Language  Independent  Rules 


the  four  rules,  listed  in  Figure  4.11,  would  be  applied  to 


each  symbol  in  the  production  rule.  Finally,  a  set  of 
attribute  equations  is  generated.  Figure  4.12  outlines  the 
details  of  the  generation  of  the  attribute  equations  for 
this  example. 


PRODUCTION  RULE  ->  X  :  A  B  C  D 

1.  Assume  A  is  a  keyword  (standard),  B  is  a  nonterminal 

C  is  a  terminal,  D  is  a  comment 

2.  A.str_value  =  [ "\n" ,X. indent, Keyword] 

A. ecursor  =  len(X. indent)  +  ien( Keyword) 

3.  B.bcursor  «  A.ecursor 

Nonterminal .bcursor  =  if  (B.bcursor  <  0) 

then  len( padding) 
else  B.bcursor 

Nonterminal .padding  =  X. padding 
Nonterminal . indent  =  [X. indent,  "  "] 

B. str_value  -  if  (B.bcursor  <  0) 

then  [X. padding, Nonterminal . st revalue] 
else  Nonterminal. str_value 

4.  C. bcursor  =  B.ecursor 

C. str_value  =  if  (C. bcursor  +  len ( terminal ) )  <  END 

then  terminal 

else  [ "\nH ,X. padding, terminal] 

C. ecursor  *  if  (C. bcursor  +  len( terminal ) )  <  END 

then  C. bcursor  +  len ( terminal ) 
else  len(X. padding)  +  len( terminal ) 

5.  D.str_value  =  Comment . str_value 

D. ecursor  =  if  len (Comment .str_value)  >  0 

then  -1 
else  +1 

6.  X.str_value  =  [A.str_value,B.str_value,C.str_value, 

D.str_value] 

X.ecursor  =  D.ecursor 

Figure  4.12  Attribute  Equation  Generation  Example 
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In  conclusion  it  is  feasible  to  use  Kodiyak  to  make 
a  language  independent  pretty  printer  generator.  In  order 
to  do  this  a  preprocessor  is  needed  to  gather  information  on 
the  specific  language  implementation  and  any  requirements 
from  the  user.  The  preprocessor  will  take  its  gathered 
information,  translate  it  into  an  attribute  grammar  for 
pretty  printer  (using  rules  outlined  in  Figure  4.11)  and 
transmit  the  attribute  grammar  to  the  Kodiyak  compiler. 
The  Kodiyak  compiler  will  produce  the  executable  code  for  a 
pretty  printer  for  the  desired  input  language.  With  this 
method  only  one  pretty  printer  needs  to  be  written  and 
multiple  languages  can  be  pretty  printed. 
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APPENDIX  A 


I  version  stamp  SHeader:  spec.k.v  1.5  88/02/16  13:27:58  berzlns  Exp  $ 


l  In  the  grammar,  comments  go  fro*  a  T  to  the  end  of  the  line. 

I  Tern  Inal  synbols  are  entirely  upper  case  or  enclosed  in  single  quotes  ('). 

I  Nonternlnal  synbols  are  entirely  lower  case. 

I  Lexical  character  classes  start  with  a  captial  letter  and  are  enclosed  In  {}. 
I  In  a  regular  expression,  x+  neans  one  or  nore  x's. 

I  In  a  regular  expression,  x*  neans  zero  or  tore  x's. 

I  In  a  regular  expression,  [xyz]  neans  x  or  y  or  z. 

I  In  a  regular  expression,  [Axyz]  neans  any  character  except  x  or  y  or  z. 

I  In  a  regular  expression,  [a-z]  neans  any  character  between  a  and  z. 

I  In  a  regular  expression,  .  neans  any  character  except  newline. 


I  definitions  of  lexical  classes 


Xdeflne  Digit 
Xdeflne  Int 
Xdeflne  Letter 
Xdeflne  Alpha 
Xdeflne  Blank 
Xdeflne  Quote 
Xdeflne  Backslash 
Xdeflne  Char 


[0-9] 

{Dlglt}+ 

[a-zA-Z] 

({Letter}|{Dlgit}!“  ") 

[  \t\n] 

[“] 

"\\“ 

([A"\\] ! {Backs  I  ash) {Quote} i {Backs  I  ash} {Backs  lash} ) 


I  definitions  of  white  space  and  connents 


:{Blank}+ 

: " — " ,*“\n" 


I  definitions  of  compound  symbols  and  keywords 


AND 

OR 

NOT 

IMPLIES 

IFF 


T 


«> 

"<*>  " 


LE 

GE 

NE 

NLT 

NGT 

NLE 

NGE 
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MACHINE 

MESSAGE 

MODEL 

00 

OF 

OPERATOR 

OTHERWISE 

PERIOD 

RENAME 

REPLY 

SEND 

STATE 

TEMPORAL 

TIME 

TO 

TRANSACTION 

TRANSITION 

TYPE 

VALUE 

VIRTUAL 

WHEN 

WHERE 

SECONDS 

MINUTES 

HOURS 

DAYS 

WEEKS 

NANOSEC 

MICROSEC 

MILL  ISEC 


MACHINE 

MESSAGE 

MODEL 

OD 

OF 

OPERATOR 

OTHERWISE 

PERIOD 

RENAME 

REPLY 

SEND 

STATE 

TEMPORAL 

TIME 

TO 

TRANSACTION 

TRANSITION 

TYPE 

VALUE 

VIRTUAL 

WHEN 

WHERE 

SECONDS 

MINUTES 

HOURS 

DAYS 

WEEKS 

NANOSEC 

MICROSEC 

MILL  ISEC 


INTEGER  LITERAL  :{lnt) 

REAL  LITERAL  : { Int}' . "{ Int} 

CHARLITERAL 

STR I NG_L I TERAL  : {Quote}{Char}*{Quot6} 


NAME 


:{Letter}{Alpha}* 


I  operator  precedences 
I  Xleft  weans  2+3+4  Is  (2+3)+4. 


Xleft 

Xleft 

Xleft 

Xleft 

Xleft 

Xleft 

Xleft 

Xleft 

Xleft 


IF,  DO,  EXCEPTION,  NAME,  SEMI; 

COMMA; 

SUCH; 

IFF; 

IMPLIES; 

OR; 

AND; 

NOT; 

LE,  GE,  NE,  NLT,  NGT,  NLE,  NGE,  EQV,  NEQV; 
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Xnonassoc  IN,  RANGE; 

XI eft  U,  APPEND; 

Xleft  PLUS,  MINUS; 

Xleft  MUL,  DIV,  MOD; 

Xleft  UMINUS; 

Xleft  EXP; 

Xleft  DOT,  WHERE ; 

Xleft  STAR; 

XX 

lattrlbute  declarations 

XX 

I  productions  of  the  grammar 
start 

spec 

{  ) 


spec 

:  spec  module 

{  ) 

I 

I 

{  ) 


I  A  production  with  nothing  after  the  means  the  empty  string 
I  Is  a  legal  replacement  for  the  left  hand  side. 


module 

:  function 
{  ) 

j  machine 
{  ) 

!  type 
{  ) 

|  definition 
{  } 

I  instance 
{  ) 


of  a  generic  module 


funct Ion 

;  optionally  virtual  FUNCTION  Interface  messages  concepts  END 
{  ) 

* 

I  Virtual  modules  are  for  inheritance  only,  never  used  directly. 


machine 


:  optionally  virtual  MACHINE  interface  state  messages  transactions  temporals  concepts 

END 

{  } 


type 

:  optionally  virtual  TYPE  Interface  model  messages  transactions  temporals  concepts  END 

{  } 


definition 

:  DEFINITION  Interface  concepts  END 

C  ) 


Instance 

:  optionally  virtual  INSTANCE  parametrized  name  parametrized  name  hide  renames  END 
{  ) 

» 

I  For  making  instances  or  partial  instantiations  of  generic  modules, 

I  and  for  making  Interface  adjustments  to  reusable  components 
I  by  hiding  or  changing  some  names. 

Interface 

:  NAME  forma (parameters  inherits  Imports  export 
{  ) 


I  This  part  describes  the  static  aspects  of  a  module's  Interface. 

I  The  dynamic  aspects  of  the  Interface  are  described  In  the  messages. 

I  A  module  Is  generic  iff  It  has  parameters. 

I  The  parameters  can  be  constrained  by  a  WHERE  clause. 

I  A  module  can  Inherit  the  behavior  of  other  modules. 

I  A  module  can  Import  concepts  from  other  modules. 

I  A  module  can  export  concepts  for  use  by  other  modules. 

Inherits 

:  inherits  INHERIT  parametrized  name  hide  renames 

{  ) 

I 

I 

{  ) 


I  ancestors  are  generalizations  or  simplified  views  of  a  module 
I  an  actor  inherits  all  of  the  behavior  of  Its  ancestors 

hide 

:  HIDE  name  1 1st 

{  ) 

I 

I 

{  } 
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I  Useful  for  providing  fin) ted  views  of  an  actor. 

I  Different  user  classes  say  see  different  views  of  a  system. 
1  Messages  and  concepts  can  be  hidden. 

renames 

:  renames  RENAME  NAME  AS  NAME 

{ } 

I 

f 

{ } 


I  Renaming  Is  useful  for  preventing  name  conflicts  when  Inheriting 
l  from  multiple  sources,  and  for  adapting  modules  for  new  uses. 

I  The  parameters,  model  and  state  components,  messages,  exceptions, 
I  and  concepts  of  an  actor  can  be  renamed. 

imports 

:  Imports  IMPORT  name  list  FROM  parametrized  name 

{  } 

I 

I 

{  } 


export 

:  EXPORT  namelist 

{  ) 

I 

'  {  ) 


messages 

:  messages  message 

{  } 

I 

* 

{  ) 


message 

:  MESSAGE  message  header  operator  response 
{  ) 


response 

:  response  body 
{  ) 

!  response  cases 
{  ) 


responsecases 

:  WHEN  expression  list  response  body  response  cases 
{  ) 

|  OTHERWISE  response  body 
{  ) 


responsebody 

:  choose  reply  sends  transition 
{  } 


choose 

:  CHOOSE  '('  field  list  restriction  ')' 

{  ) 

I 

'  {  ) 
reply 

:  REPLY  message  header  where 
l  } 

!  GENERATE  message  header  where  I  used  In  iterators 

{  ) 

I 

I 

(  ) 


sends 

:  sends  send 
{  ) 

1 

* 

{  ) 


send 

:  SEND  messageheader  TO  parametrized  name  where  foreach 
{  ) 


transition 

:  TRANSITION  expression  list  I  for  describing  state  changes 

{  ) 

I 

I 

{  ) 


messageheader 

:  optional  exception  optional  name  formal  arguments 
{  ) 


where 

:  WHERE  expression  list 
{  } 

i  Xprec  SEMI  I  «ust  have  a  lower  precedence  than  WHERE 
{  } 


optional ly  virtual 

:  VIRTUAL 

{  ) 

I 

I 

{  ) 


optional  exception 
:  EXCEPTION 
{  } 

!  Xprec  SEMI 
{  ) 


operator 

:  operator  OPERATOR  operator  list 

{  ) 

I 

I 

{  ) 


foreach 

:  FOREACH  '('  field  list  restriction  ')' 

{  ) 

I 

I 

{  ) 

l  FOREACH  is  used  to  describe  a  set  of  messages  to  be  sent, 
concepts 

:  concepts  concept 

{  ) 

I 

i 

{  ) 


concept 

:  CONCEPT  NAME  foraal  parameters  type_spec  where 
I  constants 
{  ) 

!  CONCEPT  NAME  foraal  paraaeters  foraal  arguments  where  VALUE  forma l_arguments  where 
I  functions 
{  ) 
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■ode I  I  data  types  have  conceptual  models  for  values 

:  MODEL  foreal  arguments  Invariant 
{  ) 

!  MODEL  forma i_arguments  Invariant  Initially 
I  Initially  clause  specifies  automatic  variable  initialization 
{  ) 


state  I  machines  have  conceptual  models  for  states 

:  STATE  formal  arguments  Invariant  Initially 
{  ) 


invariant  1  invariants  are  true  In  all  states 

INVARIANT  expression  list 
{  ) 


Initially  I  Initial  conditions  are  true  only  at  the  beginning 

:  INITIALLY  expression  list 
{  ) 


transactions 

:  transactions  transaction 
{  ) 

1 

'  {  ) 


transaction 

:  TRANSACTION  parametrized  name  action  expression  where 
{  ) 
t 

I  Transactions  are  atomic. 

I  The  where  clause  can  specify  timing  constraints, 
actlonexpresslon 

:  action  expression  V  action  list  Jprec  SEMI  I  sequence 
{  } 

i  action  list 
{  } 


act  lonj  1st 

:  action  list  action  list  Xprec  STAR  I  parallel 
{  } 

!  IF  alternatives  FI  I  choice 
{  } 

i  DO  alternatives  00  I  repetition 
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{  } 

!  parametrized  name  I  a  normal  message 

{  } 

|  EXCEPTION  parametrlzed_name  I  an  exception  message 

{  } 


alternatives 

:  alternatives  OR  guard  action  expression 
{  } 

I  guard  action  expression 
{  ) 


guard 

:  WHEN  expression  ARROW 

{  ) 
i 
I 

{  ) 


temporals 

:  temporals  temporal 
{  ) 

! 

{ ) 


temporal 

:  TEMPORAL  NAME  inhere  response 
{  } 

» 

!  Temporal  events  are  trigged  at  absolute  times, 

I  in  terms  of  the  local  clock  of  the  actor. 

I  The  "where"  describes  the  triggering  conditions 
!  In  terms  of  "TIME"  and  ’PERIOD". 

forma l_parameters  !  parameter  values  are  determined  at  specification  time 

:  f leldl  1st  ')'  where 

{  ) 

! 

{ ) 


formal  arguments  I  arguments  are  evaluated  at  run-time 

:  T('  f leld  l  1st  ')' 

{  ) 

! 

{ } 
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f  I  e  I  d_ I ist 

ffleld  list  field 
{  } 

i  field 
{  ) 


field 

:  name  list  ' : '  type  spec 
{  }  " 


!  '$'  NAME  ' 

{  } 

!  '?' 

{  ) 

> 

type_spec 

type  spec 

parametrized  name  I  name  of  a  data  type 

{  } 

TYPE  actual  parameters 
{  ) 

FUNCTION  actual_parameters 
{  } 

MACHINE  actual_parameters 
{  ) 

ITERATOR  actual_parameters 
{  } 

'?' 

{  ) 


name_l Ist 

:  namejlst  NAME 
{  ) 

|  NAME 
{  } 


optional_name 

:  NAME  formal  parameters 

{  ) 

I 

'  (  ) 


parametrlzed_name 

:  NAME  actual  parameters 
{  ) 


actua l_parameters  I  parameter  values  are  determined  at  specification  time 
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'{'  arg  list  '}' 

{  ) 

Xprec  SEMI  I  must  have  a  lower  precedence  than 

{  } 


actual_arguments  I  arguments  are  evaluated  at  run-time 

:  '('  arg  list  ')' 

{  } 

i  Xprec  SEMI  I  must  have  a  lower  precedence  than  '(' 

{  } 


arg_l 1st 

:  arg  list  arg  Xprec  COMMA 

{  f 

!  arg 

{  ) 


arg 

:  expression 

{  ) 

|  pair 

{  } 


expressionj  1st 

:  expression  list  expression  Xprec  COMMA 

{  ) 

!  expression 

{  ) 


expression 

:  quantifier  ’('  field  list  restriction  BIND  expression  ')' 

{  ) 

!  parametrized  name  actual  arguments 
{  ) 

!  parametrized  name  parametrized  name  actual  arguments 

(  ) 

!  NOT  expression  Xprec  NOT 

{  ) 

j  expression  AND  expression  Xprec  AND 

{  } 

!  expression  OR  expression  Xprec  OR 

{  ) 

!  expression  IMPLIES  expression  Xprec  IMPLIES 

{  ) 

!  expression  IFF  expression  Xprec  IFF 

{  ) 
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expression  '<*  expression  Xprec  L£ 

{  ) 

expression  '>'  expression  Xprec  LE 

{  } 

expression  expression  Xprec  LE 
{  ) 

expression  LE  expression  Xprec  LE 

{  } 

expression  GE  expression  Xprec  LE 

{  } 

expression  NE  expression  Xprec  LE 

{  ) 

expression  NLT  expression  Xprec  LE 

r  ) 

expression  NGT  expression  Xprec  LE 

{  ) 

expression  NLE  expression  Xprec  LE 

C  } 

expression  NGE  expression  Xprec  LE 

{  } 

expression  EQV  expression  Xprec  LE 

{  ) 

expression  NEQV  expression  Xprec  LE 
(  } 

expression  Xprec  UMINUS 

{  ) 

expression  '+'  expression  Xprec  PLUS 

{  ) 

expression  expression  Xprec  MINUS 

(  ) 

expression  expression  Xprec  MUL 

{  ) 

expression  '/'  expression  Xprec  DIV 

{  ) 

expression  MOD  expression  Xprec  MOO 

{  ) 

expression  EXP  expression  Xprec  EXP 

{  } 

expression  U  expression  Xprec  U 

(  } 

expression  APPEND  expression  Xprec  APPEND 
{  } 

expression  IN  expression  Xprec  IN 

{  ) 

expression  Xprec  STAR 

l  *x  Is  the  value  of  x  before  a  transition 
l  x  Is  the  value  after  the  transition 
{  } 

i  expression  Xprec  DOT 

1  $x  represents  a  collection  of  lte«s  rather  than  Just  one 
I  si  «  {x,  $s2)  neans  si  «  unlon({x},  s2) 
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!  si  «  [x.  $s2]  leans  si  ■  append([x],  s2) 

(  } 

;  expression  RANGE  expression  Spree  RANGE 
I  x  In  [a  ..  b]  Iff  x  in  {a  ..  b}  Iff  a  <«  x  <«  b 
I  [a  ..  b]  Is  sorted  In  increasing  order 
{  } 

I  expression  NAME  Spree  DOT 

{  } 

I  expression  '['  expression  ']'  Spree  DOT 
{  } 

I  '('  expression  ')' 

{  ) 

!  '('  expression  units  ')'  I  tiling  expression 

{  ) 

I  TIME  I  The  current  local  tlae,  used  in  teiporal  events 

{  ) 

!  DELAY  I  The  time  between  the  triggering  event  and  the  response 
{  ) 

!  PERIOD  I  The  time  between  successive  events  of  this  type 
{  ) 

i  literal 
{  ) 

!  literal  paraaetrized  na«e  I  literal  with  explicit  type 
{  } 

I  '?'  I  An  undefined  value  to  be  specified  later 

{  ) 

I  'I'  I  An  undefined  and  illegal  value 

{  ) 

!  IF  expression  THEN  expression  Middle  cases  ELSE  expression  FI 
{  ) 


alddle_cases 

:  Riddle  cases  ELSE  IF  expression  THEN  expression 

{  ) 

I 

I 

{  ) 


quantifier 
:  ALL 
{  ) 

I  SOME 
{  ) 

!  NUMBER 
{  } 

I  SUM 
{  } 

|  PRODUCT 
{  } 

!  SET 
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{ ) 

!  MAXIMUM 

{  ) 

!  MINIMUM 

{  } 

i  UNION 
{  } 

INTERSECTION 
{  ) 


restriction 

:  SUCH  expression 

(  } 

I 

I 

{  ) 


l iteral 

:  INTEGER  LITERAL 
{  ) 

!  REAL  LITERAL 
{  )  ' 

!  CHAR  LITERAL 
{  )  " 

!  STRING  LITERAL 
{  ) 

!  NAME  I  enumeration  type  literal 

{  ) 

i  '['  expressions  ']'  1  sequence  literal 

{  ) 

!  '{'  expressions  I  set  literal 

{  ) 

!  expression  expressions  I  map  literal 

{  ) 

I  '['  pair  1 1st  ']'  I  tuple  I  Iteral 

{  ) 

I  '{'  pair  '}'  l  one  of  l  iteral 

(  ) 


I  relation  literals  are  sets  of  tuples 

expressions 

:  expression  list 
{  ) 

! 

t ) 


pair  list 
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pair  list  ' , '  pair 
(  }  " 

NAME  pair 

{  } 


pair 


{  } 


:  NAME  BIND  expression 

{  ) 


units 

:  NANOSEC 

{  } 

!  MICROSEC 

{  } 

!  MILL ISEC 

{  } 

i  SECONDS 

{  } 

!  MINUTES 

{  ) 

!  HOURS 

{  ) 

!  DAYS 

{  ) 

|  REEKS 

{  ) 


operatorl  1st 

:  operator  list  operator_symbo I 

{  ) 

!  operator_symbol 

{  ) 


operator  symbol 
:  NOT 
{  ) 

|  AND 

{  ) 

|  OR 

{  ) 

I  IMPLIES 

{  } 

;  IFF 

{  ) 
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{ } 

{ } 

{ } 

LE 
{  } 

GE 
{  } 

NE 
{  3 
NLT 
{  ) 

NGT 
{  } 

NLE 
{  ) 

NGE 
{  } 

EQV 

{  } 
NEQV 
{  ) 

V 

{  ) 

»  t 

{  ) 

'  *' 

{  ) 

■/■ 

{  ) 

MOD 

{  } 

EXP 
{  ) 

U 

{  ) 

APPEND 

{  ) 

IN 

{  } 

RANGE 

{  ) 
t  * 

{  ) 

{  ) 


APPENDIX  B 


I  version  stamp  SHeader:  spec.k.v  1.5  88/02/28  13:27:58  berzlns  Exp  $ 

I  In  the  grammar,  comments  go  from  a  “I"  to  the  end  of  the  line. 

I  Terminal  symbols  are  entirely  upper  case  or  enclosed  in  single  quotes  ('). 

I  Nonterminal  symbols  are  entirely  lower  case. 

I  Lexical  character  classes  start  with  a  captlal  letter  and  are  enclosed  in  {}. 
I  In  a  regular  expression,  x+  means  one  or  more  x's. 

I  In  a  regular  expression,  x*  means  zero  or  more  x's. 

1  In  a  regular  expression,  [xyz]  means  x  or  y  or  z. 

I  In  a  regular  expression,  [Axyz]  means  any  character  except  x  or  y  or  z. 

I  In  a  regular  expression,  [a-z]  means  any  character  between  a  and  z. 

1  In  a  regular  expression,  .  means  any  character  except  newline. 

I  definitions  of  lexical  classes 


Xdeflne  Digit 
Xdeflne  Int 
Xdeflne  Letter 
Xdeflne  Alpha 
Xdeflne  Blank 
Xdeflne  Ouote 
Xdeflne  Backslash 
Xdefine  Char 


[0-9] 

{Dlglt}+ 

[a-zA-Z] 

((Letter }J {Digit} !“  “) 

[  \t\n] 

["3 

*\\" 

(tA“\\] I {Backs  I  ash) (Quote) j {Backs  I  ash) {Backs  I  ash}) 


I  definitions  of  white  space  and  comments 


:{Blank}+ 

COMMENT  ”.*"\n" 


definitions  of  compound  symbols  and  keywords 


AND 

OR 

NOT 

IMPLIES 

IFF 


LE 

GE 

NE 

NLT 

NGT 

NLE 

NGE 
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EQV 

NEQV 


RANGE 

M  M 

APPEND 

“11“ 

1  1 

MOD 

(Backslash) | MOD 

EXP 

BIND 

ARROW 

M  m 

-> 

IF 

IF 

THEN 

THEN 

ELSE 

ELSE 

IN 

IN 

U 

U 

ALL 

ALL 

SOME 

SOME 

NUMBER 

NUMBER 

SUM 

SUM 

PRODUCT 

PRODUCT 

SET 

SET 

MAXIMUM 

MAXIMUM 

MINIMUM 

MINIMUM 

UNION 

UNION 

INTERSECTION 

INTERSECTION 

SUCH 

SUCH(Blank)*THAT 

ELSEJF 

ELSE (B 1 ank}* 1 F 

AS 

AS 

CHOOSE 

CHOOSE 

CONCEPT 

CONCEPT 

DEFINITION 

DEFINITION 

DELAY 

DELAY 

DO 

DO 

ENO 

END 

EXCEPTION 

EXCEPTION 

EXPORT 

EXPORT 

FI 

FI 

FOREACH 

FOREACH 

FROM 

FROM 

FUNCTION 

FUNCTION 

GENERATE 

GENERATE 

HIDE 

HIDE 

IMPORT 

IMPORT 

INHERIT 

INHERIT 

INITIALLY 

INITIALLY 

INSTANCE 

INSTANCE 

INVARIANT 

INVARIANT 

ITERATOR 

ITERATOR 
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MACHINE 

MESSAGE 

MODEL 

OD 

OF 

OPERATOR 

OTHERWISE 

PERIOD 

RENAME 

REPLY 

SEND 

STATE 

TEMPORAL 

TIME 

TO 

TRANSACTION 

TRANSITION 

TYPE 

VALUE 

VIRTUAL 

WHEN 

WHERE 

SECONDS 

MINUTFS 

HOURS 

DAYS 

WEEKS 

NANOSEC 

MICROSEC 

MILL ISEC 


MACHINE 

MESSAGE 

MODEL 

OD 

OF 

OPERATOR 

OTHERWISE 

PERIOD 

RENAME 

REPLY 

SEND 

STATE 

TEMPORAL 

TIME 

TO 

TRANSACTION 

TRANSITION 

TYPE 

VALUE 

VIRTUAL 

WHEN 

WHERE 

SECONDS 

MINUTES 

HOURS 

DAYS 

WEEKS 

NANOSEC 

MICROSEC 

MILL ISEC 


INTEGER  LITERAL  :{lnt) 

REAL  LITERAL  :{ lnt}“ . "{ Int) 

CHAR~L ITERAL 

STR ING_L ITERAL  :{Quote}{Char}*{Quote} 


NAME  :{Letter}{Alpha}» 


I  operator  precedences 
I  Xleft  weans  2+3+4  Is  (2+3)+4. 


X I  eft 
Xleft 
Xleft 
Xleft 
Xleft 
Xleft 
Xleft 
Xleft 
Xleft 


V,  IF,  DO,  EXCEPTION,  NAME,  SEMI; 

COMMA; 

SUCH; 

IFF; 

IMPLIES; 

OR; 

AND; 

NOT; 

LE,  GE,  NE,  NLT,  NGT,  NLE,  NGE,  EOV,  NEQV; 
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Xnonassoc  IN,  RANGE; 

XI eft  U,  APPEND; 

Xleft  PLUS,  MINUS; 

Xleft  MUL,  DIV,  MOD; 

Xieft  UMINUS; 

Xleft  EXP; 

Xieft  DOT,  WHERE; 

Xleft  STAR; 

Xleft  COMMENT; 

XX 

lattrubute  declatatlons  for  nonteralnal  syebols 
start  { 

str  value:  string; 

}; 


spec  { 

Indent:  string; 
str  value:  string; 

}; 


■odule  { 

Indent:  string; 
strvalue:  string; 

}; 


function  { 

Indent:  string; 
strvalue:  string; 

); 


aachlne  { 

Indent:  string; 
str  value:  string; 

}; 


type  { 

Indent:  string; 
strvalue:  string; 

}; 


definition  { 


Indent:  string-, 
str_value:  string; 


Instance  { 

Indent:  string; 
str  value:  string; 

}; 
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interface  ( 


Indent:  string; 
str_value:  string; 
bcursor:  Int; 
padding-,  string; 

}; 


Inherits  ( 

Indent:  string; 
str_value:  string; 
bcursor:  Int; 
padding:  string; 

}; 

hide  ( 

Indent:  string; 
strvalue:  string; 
bcursor:  Int; 
padding.-  string; 

}; 

renames  { 

indent:  string; 
strvalue:  string; 
bcursor:  int; 
padding:  string; 


(■ports  { 

Indent:  string; 
str_value:  string-, 
bcursor:  int; 
padding:  string; 

}; 


export  { 

Indent:  string; 
$tr_value:  string; 
bcursor:  Int; 
padding:  string; 

}; 


Messages  { 

Indent:  string; 
str_value-.  string; 
bcursor:  Int; 
padding:  string; 

); 


■essage  { 


I 


I 
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Indent:  string; 
str_value:  string; 
bcursor:  Int; 
padding:  string; 

}; 


response  { 

Indent:  string; 
str_value:  string; 
bcursor:  Int; 
padding:  string; 

}; 


response  cases  { 

Indent:  string; 
strvalue:  string; 
bcursor:  Int; 
padding:  string; 

}; 


responsebody  { 

Indent:  string; 
strvalue:  string; 
bcursor:  Int; 
padding:  string; 

}; 

choose  { 

indent:  string; 
strvalue:  string; 
bcursor:  Int; 
padding:  string; 

); 

reply  { 

Indent:  string; 
strvalue:  string; 
bcursor:  Int; 
padding:  string; 

}; 


sends  { 

Indent:  string; 
str_value:  string; 
bcursor:  Int; 
padding:  string; 

}; 


send  { 

Indent:  string; 
str  value:  string; 
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bcursor:  int; 
padding:  string; 

); 

transition  { 

indent:  string; 
str_value:  string; 
bcursor:  Int; 
padding:  string; 

}; 

■essageheader  { 

Indent:  string; 
str_value:  string; 
bcursor.-  int; 
ecursor:  Int; 
padding:  string; 

}; 

where  { 

Indent:  string; 
strvalue:  string; 
bcursor:  Int; 
ecursor:  Int; 
padding:  string; 

}; 

optional lyvlrtual  { 

str_va!ue:  string; 
bcursor:  Int; 
ecursor:  Int; 

}; 

optional_exceptlon  { 

indent:  string; 
str_value:  string; 
bcursor:  int; 
ecursor:  Int; 
padding:  string; 

}; 

operator  { 

Indent:  string; 
str_value:  string; 
bcursor:  int; 
ecursor: Int; 
padding:  string; 

}; 

foreach  { 

indent:  string; 
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I 


}; 


str_value-.  string; 
bcursor:  Int; 
padding:  string; 


concepts  { 


Indent:  string; 
str_value:  string; 
bcursor:  Int; 

|  padding:  string; 

}; 


concept  { 

Indent:  string; 
str_value:  string; 
bcursor:  Int; 
padding:  string; 


node  I  { 

Indent:  string; 
str_value:  string; 
bcursor:  int; 
padding:  string; 

}; 


state  { 

Indent:  string; 
str_value:  string; 
bcursor:  Int; 
padding:  string; 

}; 

invariant  { 

Indent:  string; 
str_value:  string; 
bcursor:  Int; 
padding:  string; 

}; 

initial ly  { 

Indent:  string; 
str_value:  string; 
bcursor:  Int; 
padding:  string; 

}; 


transactions  { 

Indent:  string; 
str_value:  string; 
bcursor:  Int; 
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padding:  string; 

}; 


transaction  { 

Indent:  string; 
str_value:  string; 
bcursor:  Int; 
padding:  string; 

}; 


actlon_8xpresslon  { 

str  value-,  string; 
bcursor:  Int; 
ecursor:  Int; 
padding:  string; 
length:  Int; 

}; 


action  1 1st  { 

str  value:  string; 
bcursor:  Int; 
ecursor:  int; 
padding:  string; 
length:  Int; 

}; 


alternatives  { 

str_value:  string; 
bcursor:  Int; 
ecursor:  Int; 
padding:  string; 
length:  Int; 

}; 


guard  { 

str  value:  string; 
bcursor:  Int; 
ecursor:  int; 
padding:  string; 
length:  Int; 

}; 


temporals  { 

Indent:  string; 
str_value:  string; 
bcursor:  Int; 
padding:  string; 

}; 


teeporal  { 

Indent:  string; 
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str_value:  string; 
bcursor:  Int; 
padding:  string; 

}; 

foreal_paraeeters  { 

Indent:  string; 
str_value:  string; 
bcursor:  int; 
ecursor:  Int; 
padding:  string; 

}; 

forealargueents  { 

str_value:  string; 
bcursor:  Int; 
ecursor:  Int; 
padding:  string; 

); 

fleldl 1st  { 

str  value:  string; 
bcursor:  Int; 
ecursor:  int; 
padding:  string; 
length:  Int; 

}; 

field  { 

strvalue:  string; 
bcursor:  Int; 
ecursor:  Int; 
padding:  string; 
length:  int; 

}; 

typespec  { 

str_value:  string; 
bcursor:  Int; 
ecursor:  Int; 
padding:  string; 
length:  Int; 

}; 

nanej  1st  { 

str_value:  string; 
bcursor:  Int; 
ecursor:  Int; 
padding:  string; 
length:  Int; 

}; 


optional  naae  { 


Indent:  string; 
str_value.-  string; 
bcursor:  Int; 
ecursor:  Int; 
padding.-  string; 
length:  Int; 

); 

paraaetrlzed_naae  { 

str_value:  string; 
bcursor:  Int; 
ecursor:  Int; 
padding:  string; 
length:  int; 

}; 

actual  paraneters  { 

str_value:  string; 
bcursor:  Int; 
ecursor:  Int; 
padding:  string; 
length:  int; 

}; 

actual  arguments  { 

str_value:  string; 
bcursor:  Int; 
ecursor:  Int; 
padding.-  string; 
length:  Int; 

}; 

arg_l 1st  { 

strvalue:  string; 
bcursor:  int; 
ecursor:  Int; 
padding:  string; 
length:  Int; 

}; 

arg  { 

str_value:  string; 
bcursor:  Int; 
ecursor:  int; 
padding:  string; 
length:  Int; 

}; 

expression  list  { 
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str_value:  string 
bcursor:  Int; 
ecursor:  int; 
padding:  string; 
length: Int; 

}; 

expression  { 

str_value-.  string; 
bcursor:  Int; 
ecursor:  Int; 
padding:  string; 
length:  Int; 

}; 

■  Iddle  cases  { 

str_value:  string; 
bcursor-.  Int; 
padding:  string; 
length:  int; 

}; 

quantifier  { 

str  value:  string-, 
bcursor:  Int; 
ecursor:  int; 
padding:  string; 
length:  Int; 

}; 

restriction  { 

str_value;  string; 
bcursor:  Int; 
ecursor:  Int; 
padding-,  string; 
length:  int; 

}; 

literal  { 

str_value:  string; 
bcursor:  Int; 
ecursor:  Int; 
padding.-  string; 
length:  Int; 

}; 

expressions  { 

str_value:  string; 
bcursor:  Int; 
ecursor:  Int; 
padding-,  string; 
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length:  Int; 

}; 

palrj  1st  { 

str_value:  string; 
bcursor:  int; 
ecursor:  Int; 
padding:  string; 
length:  Int; 

}; 

pair  { 

str_value:  string; 
bcursor:  Int; 
ecursor:  Int; 
padding:  string; 
length:  Int; 


■ 


* 


}; 


units  { 

str_value:  string; 
bcursor:  Int; 
ecursor:  Int; 
padding:  string; 
length:  Int; 

}; 

operatorl 1st  { 

str_value:  string; 
bcursor:  Int; 
ecursor:  Int; 
padding:  string; 
length:  int; 

}; 


operator_symbol  { 

str_value:  string; 
bcursor:  Int; 
ecursor:  int; 
padding:  string; 
length:  Int; 

}; 


comment  { 

strvalue:  string; 
bcursor:  Int; 
length:  int; 

}; 


I  attribute  declarations  for  terminal  symbols 


1 

J 

-1 

i 

■i 


! 

i 

i 

! 

s 


~l 
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INTEGER  LITERAL  { 


ttext:  string; 

}; 

REAL_L ITERAL  { 

ttext:  string; 

}; 

CHAR_L ITERAL  { 

ttext:  string; 

}; 

STR ING  L ITERAL  { 

ttext:  string; 

}; 

NAME  { 

ttext:  string; 

); 

COMMENT  { 

ttext:  string; 

}; 


ti 

1  productions  of  the  grammar 
start 

:  coeeent  spec 

{ 

toutput([coaaent.str_value,  spec.str  value]); 
spec.  Indent  »  **; 
coament. bcursor  -  0; 

) 


spec 

:  spec  module 

{ 

■odu I e. Indent  -  spec [1]. Indent; 
spec[2]. Indent  «  spec[1] . Indent; 

spec[1].str  value  -  [spec[2].str  value,  aodule.str  value]; 

) 

» 

I 

{ 

spec.str  value  »  **; 

) 


I  A  production  with  nothing  after  the  "[*  aeans  the  empty  string 


I  Is  a  legal  replacement  for  the  left  hand  side. 


module 

:  function  j 

{ 

function. Indent  »  module.  Indent; 
module. str  value  •  function. str  value-, 

} 

!  machine 

{  i 

mach  I  ne .  I  ndent  •  modu  I  e .  I  ndent 
module. str  value  -  machine. str  value; 

} 

!  type 
( 

type . I ndent  •  modu I e . I ndent ;  j 

module. str  value  •  type. str  value; 

} 

I  definition 
{ 

definition. Indent  >  module. indent; 

module. strvalue  -  def  lnltlon.str_value-,  j 

!  Instance  I  of  a  generic  module 

{ 

I nstance . I ndent  -  modu I e .  I ndent ; 
module. strvalue  -  Instance. strvalue; 

>  I 


function 

:  optionally  virtual  FUNCTION  interface  messages  concepts  END  comment 

{ 

comment. bcursor  -  0; 

optional  ly  vlrtual  .bcursor  •  len(functlon.  indent); 

Interface. Indent  »  [funct Ion.  indent,  spaces (3)]; 
messages. Indent  -  [funct Ion. indent,  spaces(3)]; 
concepts. Indent  -  [function. indent,  spaces(3)]; 

Interface. bcursor  •  optional ly_vlrtual .ecursor  +  9; 

Interface. padding  «  [spaces(optlonal ly_v I rtua i .ecursor),  spaces(9)]; 

messages. bcursor  -  len(messages. Indent); 

messages. padding  •  messages. indent; 

concepts. bcursor  -  I en(concepts.  Indent); 

concepts. padding  •  concepts,  indent; 

funct Ion. str_value  -  [optional ly_vlrtual ,str_value,  "FUNCTION", 
Interface. str_value,  messages. str_value,  concepts. str_value,  "\n”, 
function.  Indent,  "END",  comment. str  value,  "\n",  "\n"]-, 

) 

• 

I  Virtual  modules  are  for  Inheritance  only,  never  used  directly. 
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aachlne 

:  optional  I y_vlrtua I  MACHINE  Interface  state  aessages  transactions  teaporals  concepts 
END  coaaent 
{ 

coaaent. bcursor  -  0; 

optional  I y_v I rtua I .bcursor  -  len(aachlne. Indent); 
interface. Indent  *  [each I ne. Indent,  spaces(3)]; 
state.  Indent  -  [each  I  ne.  Indent,  spaces(3)]-, 
aessages. Indent  -  [each I ne. indent,  spaces(3)]; 
transactions. Indent  -  [each I ne. Indent,  spaces(3)]; 
teaporals. Indent  -  [each (ne. Indent,  spaces(3)]; 
concepts. Indent  -  [each I ne. Indent,  spaces (3)]; 

Interface. bcursor  -  optional  I y_v I rtua I .ecursor  +  8; 

Interface. padding  -  [spaces(optlonal ly_vlrtual .ecursor),  spaces(8)]; 

state. bcursor  -  len(state. Indent); 

state. padding  -  state. Indent; 

aessages. bcursor  *  I en(aessages. Indent); 

aessages. padding  -  aessages. Indent; 

transact  Ions. bcursor  •  len(transactlons. Indent); 

transact  Ions. padding  -  transactions. Indent; 

teaporals. bcursor  -  len(teaporals. Indent); 

teaporals. padding  «  teaporals. Indent; 

concepts. bcursor  *  len(concepts. Indent); 

concepts. padding  -  concepts. Indent; 

aachine.str  value  -  [optlonallyvlrtual.strvalue,  "MACHINE  ", 

Interface. strvalue,  state. str_value,  aessages. str  va lue, 
transactions.str_value,  teaporals. strvalue,  concepts. str _value,  “\n", 
each  I ne. Indent,  "END",  coaaent. str  value,  "\n",  "\n"]; 

} 


:  optional  I y_v I rtua I  TYPE  Interface  aodel  aessages  transactions  teaporals  concepts 
END  coaaent 

{ 

coaaent. bcursor  »  0; 

optional  I y_v l rtua I .bcursor  »  len(type.  Indent); 

Interface. Indent  -  [type. Indent,  spaces(3)]; 
aodel. indent  -  [type. Indent,  spaces(3)]; 
aessages. Indent  -  [type. Indent,  spaces(3)]; 
transactions. Indent  -  [type. Indent,  spaces(3)]; 
teaporals. indent  -  [type. Indent,  spaces (3)]; 
concepts.  Indent  -  [type. indent,  spaces(3)]; 
interface. bcursor  -  optional  I y_v I rtua I .ecursor  +  5; 

Interface. padding  -  [spaces(optlonal ly_v I rtua I .ecursor),  spaces(5)]; 

aodel .bcursor  -  len(aodel . Indent); 

aodel .padding  -  aodel . Indent; 

aessages. bcursor  -  I en(aesscges. Indent); 

aessages. padding  -  aessages. indent; 

transact  ions. bcursor  -  len(transactlons. Indent); 

transactions. padding  »  transactions. Indent; 
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teapora Is. bcursor  -  len(teaporals. Indent); 
teapora Is. padding  -  teaporals. Indent; 
concepts. bcursor  -  I en(concepts. Indent); 
concepts. padding  -  concepts. Indent; 

type.str_value  -  [optional ly_vlrtual.str_value,  “TYPE  ",  interface. str_va lue, 
aodel .str_value,  aessages.str_value,  transact  Ions. str  va lue, 
teapora I sTstrva lue,  concepts. str_va lue,  “\n“,  type. Indent,  “EMO", 
coaaent.str_value,  “\n“.  *\n*]; 


definition 

:  DEFINITION  Interface  concepts  END  coaaent 
{ 

coaaent. bcursor  »  0; 

Interface. Indent  -  [definition. Indent,  spaces(3)]; 
concepts.  Indent  ■  [definition.  Indent,  spaces(3)]-, 

Interface. bcursor  -  len(def Inltlon. Indent)  +  11; 
interface. padding  «  [definition. Indent,  spaces(ll)]; 
concepts. bcursor  «  lenfconcepts. indent); 
concepts. padding  «  concepts. Indent; 

def Inltlon. strvalue  -  [“\n“,  definition. Indent,  “DEFINITION  “, 

Interface. str  value,  concepts. str  value,  “\n“,  “END",  coaaent. str  value,  \n“, 
“\n“]; 


Instance 

:  optional  lyvlrtual  INSTANCE  paraaetr Ized  naae  paraaetr  Ized  naae  coaaent  hide 
renaaes  END  coaaent 
{ 

optional lyvlrtual .bcursor  -  len( instance. Indent); 
hide. Indent  -  [ Instance. Indent,  spaces(3)]; 
renaaes. indent  »  [ Instance. indent,  spaces(3)]; 
coaaent [1]. bcursor  -  paraaetr lzed_naae[2]. ecursor; 
coaaent[2]. bcursor  »  0; 

paraaetr I zed_naae[1]. bcursor  «  optional  I y_v I r tua I .ecursor  + 
len( instance. Indent)  ♦  9; 

paraaetr I zed_naae[1]. padding  ■  [spaces(optional ly_vlrtual .ecursor),  spaces(9)]; 
paraaetr lzed_naae[2]. bcursor  ■  paraaetr lzed_naae[T], ecursor  +  3  <»  80 
->  paraaetr l zed_naae[1]. ecursor  +  3 
•  len(paraaetrlzed_naae[1]. padding)  ♦  2; 
paraaetr lzed_naae[2). padding  «  paraaetrlzed_na*e[l].paddlng; 
hide. bcursor  -  len(hlde. Indent); 
hide. padding  -  hide. indent; 
renaaes. bcursor  •  len( renaaes. Indent); 
renaaes. padding  -  renaaes. Indent; 

Instance. strva lue  -  paraaetr lzed_naee[lj. ecursor  +  3  <-  80 
->  [*\n“.  Instance. Indent,  optional ly_v i rtua I .strvalue,  “INSTANCE  “, 
paraaetrlzed_naee[1].str_value,  “  -  *,  paraaetr lzed_naae[2].str_va lue, 
coaaent[1].str  value,  hide. str  value,  renaaes. str  value,  “\n“. 
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Instance. Indent,  “END”,  coaaent[2].str_value,  “\n“,  "\n“] 

*  [”\n“,  instance. Indent,  optional ly_vlrtual .str_value,  "INSTANCE  ”, 

paraaetrlzed_naae[1].str_value,  “\n“,  paraaetrized_naae[1].paddlng,  "«  ”, 
paraaet  r I  zednaae [ 2] . st r_va  I ue ,  coaaent [  1  ] . st r_va  I ue ,  h  I de . st r  _va  I ue , 
renaaes.str  value,  “\n*.  Instance. Indent,  “END”,  coaaent[2].str  value,  "\n", 
*\n“]; 


I  For  aaklng  Instances  or  partial  Instantiations  of  generic  aodules, 

I  and  for  aaklng  Interface  adjustaents  to  reusable  coaponents 
I  by  hiding  or  changing  soae  naaes. 

Interface 

:  NAME  foraal  paraaeters  coaaent  Inherits  faports  export  coaaent 
{ 

foraal  paraaeters. indent  -  Interface. indent; 

Inherits. Indent  -  Interface. Indent; 
l aports. Indent  -  Interface. indent; 
export. Indent  -  Interface. indent; 
coaaent [1].bcursor  -  foraa l_paraaeters.ecursor  >  0 
->  foraa I  paraaeters. ecursor 
*  0; 

coaaent [2]. bcursor  -  0; 

foraa I  paraaeters. bcursor  •  Interface. bcursor  +  len(NAME.Xtext); 

foraa  I  paraaeters.  padding  -  [interface. padding,  spaces(len(NAME.Xtext))]; 

Inherits. bcursor  -  I en( Inherits. Indent); 

Inherits. padding  -  Inherits. Indent; 
laports. bcursor  -  len( laports. Indent); 
i aports. padding  -  laports. Indent; 
export. bcursor  -  len(export. Indent); 
export. padding  -  export. indent; 

lnterface.str_value  -  [NAME .Xtext,  foraa I  paraaeters. strvalue, 
coaaent [1 ] .str  value,  lnherlts.str_value,  laports. str  value,  export. str  value, 
coaaent[2].str  value]; 


I  This  part  describes  the  static  aspects  of  a  nodule's  Interface. 

I  The  dynaalc  aspects  of  the  Interface  are  described  In  the  aessages. 

I  A  aodule  Is  generic  iff  It  has  paraaeters. 

I  The  paraaeters  can  be  constrained  by  a  WHERE  clause. 

I  A  aodule  can  Inherit  the  behavior  of  other  aodules. 

I  A  aodule  can  laport  concepts  froa  other  aodules. 

I  A  aodule  can  export  concepts  for  use  by  other  aodules. 

Inherits 

:  Inherits  INHERIT  paraaetrlzed  naae  coaaent  hide  renaaes  coaaent 
{ 

coaaent [1]. bcursor  -  paraaetrlzed_naae. ecursor; 
coaaent[2]. bcursor  »  0; 

Inher lts[2] . Indent  »  inher lts[1 ] . Indent; 
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hide,  indent  -  [lnherlts[1].  Indent,  spaces(3)]; 
renaaes. indent  -  [lnherlts[l], indent,  spaces(3)]; 
paraaetrlzed_naae.bcursor  •  len( Inherits. indent)  +  8; 
paraaetrized_naae. padding  -  [inherits. indent,  spaces(8)]; 
hide.bcursor  •  len(hlde. Indent); 
hide. padding  -  hide. Indent; 
renaaes. bcursor  -  I en( renaaes. indent); 
renaaes. padding  -  renaaes. indent; 

lnherlts[l].str_value  ■  [lnherits[2].str_value,  “\n\  lnherlts[i],  indent, 
'INHERIT  *,  paraaetrlzednaae.strvalue,  coaaent[l].str_value,  hide. str_va lue. 
renaaes. str  value,  coaaent[2].str  value]; 

) 

t 

I 

( 

Inherits. str  value  -  "; 

) 


I  ancestors  are  generalizations  or  slapllfled  views  of  a  aodule 
I  an  actor  Inherits  all  of  the  behavior  of  Its  ancestors 

hide 

:  HIDE  naae  list  coaaent 

{ 

naael 1st. bcursor  »  hide.bcursor  ♦  5; 

name_ 1 1st. padding  -  [hide. padding,  spaces(5)]; 

coaaent. bcursor  -  namej Ist.ecursor; 

hide. strva lue  «  ["\n”,  hide. Indent,  "HIDE  “,  naael Ist.strvalue, 
coaaent. str  value]; 

) 

I 

I 

{ 

hide. str  value  - 

} 


I  Useful  for  providing  Halted  views  of  an  actor. 

I  Different  user  classes  aay  see  different  views  of  a  systea. 
l  Messages  and  concepts  can  be  hidden. 

renaaes 

:  renaaes  RENAME  NAME  AS  NAME  coaaent 

{ 

renaaes[2]. Indent  -  renaaes[l], indent; 
renaaes[2]. bcursor  -  renaaes[l]. bcursor; 
renaaes[2]. padding  -  renaaes[1]. padding; 

coaaent. bcursor  •  (len(renaaes[1], Indent)  +  7  +  len(NAME[l].Xtext)  <-  80) 
&&  ( I en(renaaes[1]. Indent)  +  7  +  len(NAME[1] .Xtext)  +  4  + 
len(NAME[2].Xtext)  >  80) 

->  len(renaaes[1], padding)  +  6  +  len(NAME[2].Xtext) 

•  len(renaaes[1]. Indent)  +  11  +  len(NAME[1].Xtext)  +  I  en(NAME [2] .Xtext ) ; 


* 


i 
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renaaes[1].str  value  -  (len(renaaes[1]. indent)  +  7  ♦  I en ( NAME [ 1 ]  .Xtext)  <•  80) 
( I en(renaaes[1]. Indent)  +  7  +  len(NAME[1].Xtext)  Hi 
len(NAM£[2].Xtext)  >  E0) 

->  [renaaes[2].str_value,  "\n‘,  renaaestl]. Indent,  'RENAME  NAME[1].Xtext, 
'\n',  renaaest?]. padding,  spaces(3),  'AS  ',  NAME[2] .Xtext , 
coaaent. str  value] 

•  [renaeest2].8tr_value,  *\n',  renaees[1]. Indent,  "RENAME  ’,  NAME[1] .Xtext , 
'  AS  '.  NAME [2]. Xtext,  coaaent. str  value]; 

} 

I 

I 

{ 

renaees.str  value  •  "j 

} 


I  Renaalng  Is  useful  for  preventing  naae  conflicts  when  Inheriting 
l  froa  aultlple  sources,  and  for  adapting  Modules  for  new  uses. 

I  The  paraaeters,  aodel  and  state  coaponents,  Messages,  exceptions, 
l  and  concepts  of  an  actor  can  be  renaaed. 

laports 

:  laports  IMPORT  naae  list  coaaent  FROM  paraaetrlzed  naae  coaaent 

{ 

laports[2]. Indent  -  laports[1]. Indent; 

coaaent [2], bcursor  -  paraaetrlzed  naae. ecursor; 

coaaent[1].bcursor  •  naae J 1st. ecursor; 

laports[2]. bcursor  -  laportstl]. bcursor; 

laports[2], padding  -  laportstl], padding; 

naae J 1st. bcursor  -  len( laportstl]. padding)  +  7; 

naae J 1st. padding  -  t laportstl]. padding,  spaces(7)]; 

paraaetrlzed  naae. bcursor  -  laports. bcursor  *  8; 

paraaetr I zed  naae. padding  -  tl«Portst1]. padding,  spaces(8)J; 

laportstl]. str_value  -  t laportst2].str_value,  '\n',  laportstl]. Indent, 

"IMPORT  ',  naael lst.str_value,  coaaent tl].str  value,  '\n',  laportstl] . indent, 
spaces(3),  "FROM  ",  paraaetrlzed  naae. str  value,  coaaent[2].str_value]; 

} 

! 

t 

laports. str  value  «  '*; 

} 


export 

:  EXPORT  naae  list  coaaent 

{ 

naae  1 1  st. bcursor  »  export. bcursor  ♦  7; 
coaaent. bcursor  ■  naae_ 1 1st. ecursor; 
naae_ l 1st .padding  -  [export .padding,  spaces(7)]; 
export. str_value  -  f\n't  export,  indent,  'EXPORT',  naael  Ist.strvalue, 
coaaent. str  value]; 

} 
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export. str  value 


•essages 

;  lessages  aessage 


{ 


} 


aessages[2]. Indent  -  aessages[1]. Indent; 

■essage. indent  •  aessages[l]. Indent; 

■essages[2] .bcursor  «  aessages[1].bcursor; 

■essages[2]. padding  •  aessages[1], padding; 

Message. bcursor  -  ae$sages[1]. bcursor; 

Message. padding  -  aessages[l]. padding; 

messages[1].str_value  -  [aessages[2].str_value,  Bessage.str_value]; 


messages. str  value 


aessage 


:  MESSAGE  aessage  header  operator  coaaent  response 

f 


{ 


} 


aessageheader.  indent  -  [message.  Indent,  spaces(3)]; 
operator. Indent  •  [message. indent,  spaces(3)]; 
response,  indent  «  [Message. Indent,  spaces(3)]; 
coaaent. bcursor  -  operator. ecursor; 
aessageheader.  bcursor  •  aessage. bcursor  +  8; 
aessageheader. padding  «  [aessage. padding,  spaces(8)]; 
operator. bcursor  -  aessage_header .ecursor  >  0 
->  aessageheader. ecursor 
#  aessage  header. bcursor; 
operator. padding  -  spaces(operator .bcursor); 
response. bcursor  »  len( response. Indent); 
response. padding  •  response.  Indent; 

message. str  value  »  ["\n“,  "\n",  aessage. Indent,  "MESSAGE  ", 
aessage_header . st r_va I ue ,  operator . st r_va I ue ,  comment . str_va I ue , 
response. str  value]; 


-1 


response 

:  response  body 

{ 

response_body. Indent  «  response. Indent; 
response_body. bcursor  «  response. bcursor; 
response_body. padding  ■  response. padding; 
response. str  value  »  response  body ,str_value; 
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) 

!  response  cases 

{ 

response_cases. Indent  «  response. Indent; 
response_cases.bcursor  »  response. bcursor; 
response_cases. padding  -  response. padding; 
response. str  value  ■  response  cases. str  value; 

} 


responsecases 

:  WHEN  expression  list  coaaent  response  body  response  cases  coaaent 
{ 

responsebody.  Indent  -  [response_cases[1].  Indent,  spaces(3)]; 
response_cases[2]. Indent  -  response_cases[l] . Indent; 
comaenttT]. bcursor  -  expresslonj 1st .ecursor; 
coaaent[2], bcursor  -  0; 

expression! 1st. bcursor  ■  response_cases[1] .bcursor  +  5; 
expresslonj 1st. padding  «  [response_cases[l] .padding,  spaces(5)]; 
response  body. bcursor  -  response_cases[1]. bcursor; 
respor ie  body . padding  -  response_cases[1]. padding; 
response_cases[2]. bcursor  -  response_cases[1]. bcursor; 
response_cases[2]. padding  •  response  cases[1] .padding; 
response_cases[1].str_value  «  C“\n*,~response_cases[1]. Indent,  "WHEN  ", 
express  I on_ list. st  r  _va I ue ,  coaaent [ 1 ] . st  r_va I ue ,  responsebody . st  r_va I ue , 
response  cases[2].str_value,  coa*ent[2].str_value]; 

} 

!  OTHERWISE  response  body 
{ 

response  body.  Indent  -  [response_cases.  Indent,  spaces(3)]; 
response  body. bcursor  -  response  cases. bcursor  +  10; 
response  body. padding  -  [ response jases. padding,  spaces(10)1; 
response_cases.str_value  «  [’\n’t  response_cases. Indent,  "OTHERWISE  ”, 
response  body. str  value]; 

} 


responsebody 

:  choose  reply  sends  transition  coaaent 
( 

coaaent. bcursor  «  0; 
cho. -je . 'ndent  -  response_body.  Indent; 
reply. indent  -  response_body. Indent; 
sends. Indent  «  response_body. Indent; 
transit  Ion. indent  -  response Jiody. Indent; 
choose. bcursor  •  I en(choose. Indent); 
choose. padding  •  choose. Indent; 
reply. bcursor  -  len(reply. Indent); 
reply. padding  ■  reply. Indent; 
sends. bcursor  «  len(sends.  indent); 
sends. padding  «  sends. Indent; 


i 


transltion.bcursor  »  len(transltion. indent); 
transition. padding  »  transition. Indent; 

response  body.str  value  «  [choose. str_value,  reply. str_value,  sends. str_value, 
transition. str  va  I  ue,  comment,  strja  lue];  I 


choose 

:  CHOOSE  '('  field  list  restriction  ')'  comment 
{ 

field  llst.bcursor  -  choose. bcursor  +  7  <  80 
->  choose. bcursor  +  7 

*  choose. bcursor  +  3; 

comment, bcursor  -  restrict  Ion. ecursor  +  1; 

field  1 1st. padding  -  choose. bcursor  +  7  <  80 
->  [choose. padding,  spaces(7)] 

«  [choose. padding,  spaces(3)]; 

restrict  Ion. bcursor  ■  fleldj 1st. ecursor  +  restriction. length  +  l  <-  80 
->  fleldj  1st. ecursor 

•  len(fTeld_l 1st. padding); 

restriction. padding  -  choose. bcursor  ♦  7  <  80 

->  [choose. padding,  spaces(7)] 

»  [choose. padding,  spaces(3)]; 

choose. str  value  -  (choose. bcursor  +  7  <  80)  88  (restriction. length  —  0) 

->  [-\n* 7  choose.  Indent,  "CH00SE(“,  f  leldj  Ist.str  value,  restrlctlon.str  value, 
■)",  comment. st r_va I ue] 

«  (choose. bcursor  +  7  >■  80)  88  (restriction. length  »«  0) 

->  ["\n“,  choose. Indent.  "CHOOSE *,*\n",  spaces (choose. bcursor),  spaces(3),  "(“, 
f leldl 1st. str  value,  restrlctlon.strvalue,  ")",  comment. str_value] 

«  (choose. bcursor”+  7  <  80)  88  (fleld_l lit. ecursor  + 
restriction. length  +  1  <-  80) 

->  [“\n",  choose,  indent,  "CH00SE(\  f  ield_l  ist.str_value,"  ", 
restrlctlon.strvalue,  ")",  comment. str_va lue] 

«  (choose. bcursor  +  7  >«  80)  88  (fleldj 1st .ecursor  + 
restriction. length  +  1  <«  80) 

->  [“\n“,  choose. indent,  "CHOOSE “,’\n",  spaces(choose. bcursor),  spaces(3),  "(", 
field  l 1st .str_va lue ,  "  ",  restriction.str  jalue,  ")",  comment. str_value] 

«  (choose. bcursor  +  7  <  80)  88  (fleldj  1st  .ecursor  + 
restriction. length  +  1  >  80) 

->  [“\n“,  choose. Indent,  "CH00SE(",  f ield_llst.str_value,"\n”, 

fleldj 1st. padding,  restrict  Ion. str_value,  ")",  comment. strva lue] 
a  [”\n",  choose.  Indent,  "CHOOSE", "\n’,"spaces(choose. bcursor),  spaces(3), 

"(",  field  l lst.str_value,"\n",  fleld_l 1st. padding,  restrictlon.str_value, 
")’,  comment  .str  value]; 

} 

I 

I 

{ 

choose. str  value  ■  ""; 

} 
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reply 

:  REPLY  aessage  header  coiaent  where 

{ 

coeeent.bcursor  -  «essage_header.ecursor  >  0 
->  aessage_header.ecursor 
•  0; 

aessageheader .  1  ndent  -  rep  I  y .  I  ndent ; 
where. Indent  -  [reply. Indent,  spaces(3)]; 
aessage_header.bcursor  •  reply.bcursor  +  6; 
aessage_header. padding  -  [reply. padding,  spaces(6)]; 
where. bcursor  -  len(where. indent); 
where. padding  -  where. Indent; 

reply.str_value  -  [”\n‘,  reply. Indent,  ‘REPLY  ",  aessage _header.str_va I ue, 
coaaent.str  value,  where. str  value]; 

) 

I  GENERATE  aessage  header  coaaent  where  I  used  In  iterators 
{ 

coaaent. bcursor  -  aessage_header.ecursor  >  0 
->  aessage  header. ecursor 
*  0; 

aessageheader.  Indent  -  reply.  Indent; 
where. indent  -  [reply. Indent,  spaces(3)]; 
aessage  header. bcursor  -  reply.bcursor  +  9; 
aessage  header. padding  -  [reply. padding,  spaces(9)]; 
where. bcursor  -  len(where. Indent); 
where. padding  -  where. Indent; 

reply. strvalue  -  [‘\n“,  reply. Indent,  "GENERATE  aessage  header. strvalue, 
coaaent.str  value,  where. str  value]; 

} 

I 
I 

{ 

reply. str  value  «  “; 

} 

I 

sends 

.-  sends  send 
{ 

sends[2]. Indent  »  sends[1]. Indent; 
send. Indent  -  sends [1], Indent; 
sends[2]. bcursor  -  sends[1]. bcursor; 
sends [2]. padding  -  sends[1]. padding; 
send. bcursor  -  sends[1]. bcursor; 
send. padding  •  sends[1]. padding; 

sends[1].str  value  -  [sends[2].str  value,  send. str  value]; 

} 

I 

I 

{ 

sends. str  value  -  “; 


) 


I 


send 

:  SEND  eessage  header  TO  paraaetrlzed  naae  coaaent  where  foreach 
{ 

coaaent. bcursor  -  paraaetrlzed_naae. ecursor; 

«essage_header .  Indent  -  [send. Indent,  spaces(3)]; 
where. Indent  -  [send. Indent,  spaces(3)]; 
foreach. Indent  -  [send. Indent,  spaces(3)]; 

■essage_header .bcursor  -  send. bcursor  +  5; 

■essage  header . padding  -  [send. padding,  spaces(5)]; 

paraaetrlzed_naae. bcursor  -  send. bcursor  +  3; 

paraaetr I zednaae. padding  -  [send. padding,  spaces(6)]; 

where. bcursor  «  len(where. Indent); 

where. padding  -  where. indent; 

foreach. bcursor  -  len(foreach. Indent); 

foreach. padding  •  foreach.  Indent; 

send.strvalue  ■  ["\n“,  send.  Indent,  'SEND  ",  aessage  header.str  value,  ”\n", 
send. Indent,  spaces(3),  “TO  “,  paraaetrlzed_naae.str_value,  comment. str_vaiue, 
where. str  value,  foreach. str  value]; 

) 


transition 

:  TRANSITION  expression  list  coaaent  I  for  describing  state  changes 
{ 

expression!  1st. bcursor  -  transit  Ion. bcursor  +  11; 
comment. bcursor  -  expression! 1st. ecursor; 
expression  ! 1st. padding  -  [transition. padding,  spaces(ll)]; 
transit  Ion. str_value  -  ["\n",  transition. Indent,  "TRANSITION  ", 
expression  llst.strvalue,  coaaent. str  value]; 

) 


transition. str  value  »  *"; 

) 


I 


I 


■ 


! 


aessage_header 

;  optlonal_exceptlon  optlonal_naae  foraal_arguaents 

<  I 

opt  Iona  I  naae.  indent  -  aessageheader.  Indent; 

opt  Iona  I  except  Ion. Indent  -  aessage_header . padding; 
optlonal_exceptlon.bcursor  -  aessage_header. bcursor; 
opt  Iona l_except Ion. padding  -  message  header. padding; 
opt  Iona  I _naae. bcursor  ■  optlonal_exceptlon. ecursor; 

opt  Iona  I _naae. padding  •  spaces ( opt  I ona I _except ion. ecursor);  I 

foraal_arguaents. bcursor  ■  opt  I ona I _na»e. ecursor  <  0 
->  opt  Iona  I _name. bcursor 

•  opt  Iona  I _naae. length  —  0 
->  opt  Iona l _naae. ecursor 

*  len(optlonal_naae. Indent); 

! 
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foraal_arguaents. padding  -  spaces(foraal_arguaents. bcursor); 
aessageheader .ecursor  -  foraa  I  arguaents.ecursor; 
aessage_header.str_value  -  opt  Iona  I _naae. ecursor  <  o 
->  [optlonal_exceptlon.str_value,  optional_name.str_value,  optional  name. indent, 
foraa larguaents .strva lue] 

•  opt iona7_naae. length  —  0 

->  [optlonaT_exceptlon.str_value,  opt ional_naae.str_value, 
foraa I _arguaent s . st  r_va I ue] 

•  [optlonal_exception.str_value.  optlonal_naae.str_value,  "\n“, 

opt  I ona I  naae . f  ndent , foraa I _arguaent s . s t  r _va I ue ] ; 


where 

:  WHERE  expression  list  coaaent 

{ 

coaaent .bcursor  -  express ion_l 1st .ecursor; 
expression! 1st. bcursor  -  I en{where. Indent)  +  6; 
express l on_ 1 1 st. padding  -  [where. Indent,  spaces(6)]; 
where. ecursor  •  coaaent. length  >  0 
-»  -1 

•  expression! 1st. ecursor; 

where.str_value  ■  f\n",  where.  Indent,  "WHERE  ",  expression! ist.strvalue, 
coaaent. str  value]; 

} 

|  Xprec  SEMI  I  aust  have  a  lower  precedence  than  WHERE 

{ 

where. ecursor  -  where. bcursor; 
where. str  value  - 

) 


optionally  virtual 
:  VIRTUAL 

{ 

optional  ly  vlrtua I  .ecursor  -  optional  I y_v I rtua I  .bcursor  +  8; 
optionally  virtual. str  value  «  [*\n",  "VIRTUAL  ’]; 

} 

! 

{ 

optional  I y_v I rtua I .ecursor  -  opt  I ona 1 1 y_v I rtua I .bcursor  +  0; 
optionally  virtual. str  value  ■  ""; 

} 


optional  exception 
:  EXCEPTION 
{ 

optlonal_exceptlon.ecursor  -  optlonal_exceptlon.bcursor  +  10; 
optional  exception. str  value  -  "EXCEPTION  "; 

} 
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Spree  SEMI 


{ 

opt  Iona  I _except  ion.ecursor  -  optlonal_exception.bcursor; 
optional  exceptlon.str  value  « 

} 


operator 

:  operator  OPERATOR  operator  list 
{ 

operator[2].bcursor  -  operator[1].bcursor; 
operator[2]. padding  -  operator[l]. padding; 

operator_l Ist.bcursor  -  operator[2].ecursor  +  10  +  operatorj 1st.  length  <•  80 
->  operator[2].ecursor  +  10 

•  len(operator[1]. padding)  +  9; 

operatorj 1st. padding  «  spaces(operator_l 1st .bcursor); 
operator[1].ecursor  -  operatorj Ist.ecursor; 

operator[1].str_value  ■  operator[2].ecursor  +  10  +  operator  1 1st.  length  <=  80 
->  [operator[2].str_value,  *  OPERATOR  operator  1 1st. str  value] 

•  [operator[2].str_value,  "\n“,  operator [1]. padding,  "OPERATOR  ", 

operator  j  Ist.str  value]; 

} 

I 

I 

{ 

operator. ecursor  -  operator. bcursor; 
operator. str  value  -  *'; 

} 


foreach 

:  FOREACH  '('  field  list  restriction  ')'  consent 
{ 

fleldl Ist.bcursor  *  foreach. bcursor  +  8  <  80 
->  foreach. bcursor  +  8 

•  I en(foreach. Indent)  +  4; 

fleldj 1st. padding  «  [foreach. padding,  spaces(8)]; 
restrict  I  on. bcursor  -  fleldj  Ist.ecursor; 
restriction. padding  -  fleldj  1st. padding; 
consent. bcursor  «  restrict Ion.ecursor  +  1; 

foreach.str jalue  -  (foreach. bcursor  +  8  <  80)  U  (restriction. length  ««  0) 

->  ["\n",  foreach.  Indent,  "FOREACHC,  f  ieldj  Ist.str  jalue, 
restrlctlon.str jalue,  ")",  consent. str_va I ue] 

•  (foreach. bcursor  +  8  >-  80)  &&  (restr lotion. length  •«  0) 

->  ["\n",  foreach. Indent,  “FOREACH",  *\n“,  foreach. Indent,  spaces(3),  "(", 
f  leld  l  lst.str_vaiue,  restrlctlon.strjalue,  “)',  consent. str_va I ue] 

•  (foreach. bcursor  +  8  <  80)  &&  (restriction. length  >  0) 

->  [“\n“,  foreach. Indent,  “FOREACHC,  f  leld_l  lst.str_value,  “  ", 
restrlctlon.str_value,  “)“,  cossent.str_value] 

•  [“\n",  foreach.  Indent,  “FOREACH*,  “\n“,  foreach. Indent,  spaces(3),  "(", 

field  I  Ist.str  value,  ”  “,  restriction. str  value,  “)“,  consent. str  value]; 
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I 

I 


{ 

foreach.str  value  -  *"; 

} 

i 

I  FOREACH  is  used  to  describe  a  set  of  aessages  to  be  sent. 

concepts 

:  concepts  concept 
{ 

concept. Indent  ■  concepts[l]. Indent; 
concepts[2]. Indent  -  concepts [1]. Indent; 
concepts[2].bcursor  -  concepts[1].bcursor; 
concepts [2]. padding  -  concepts[1]. padding; 
concept. bcursor  -  concepts[1].bcursor; 
concept. padding  -  concepts [1]. padding; 

concepts[l].str_value  -  [concepts[2].str  value,  concept. strvalue]; 

} 

I 

I 

{ 

concepts. strvalue  » 

} 


concept 

:  CONCEPT  NAME  foraal_paraaeters  type_spec  coaaent  where 
I  constants 
{ 

coaaent. bcursor  -  typespec.  ecursor; 

foraa ^parameters. Indent  -  [concept. Indent,  spaces(3)]; 

where. Indent  -  [concept. Indent,  spaces(3)]; 

foraa Iparaaeters. bcursor  -  concept .bcursor  +  8  +  len(NAME.Xtext); 
foraa Iparaaeters. padding  •  [concept. padding,  spaces(8),  spaces! len(NAME.Xtext))]; 
typespec.  bcursor  •  foraal_paraaeters.ecursor  <  0 
->  len(foraal_paraaeters. padding)  +  2 

•  forma Iparaaeters. ecursor  +  2  <»  80 
->  foraa I  paraaeters. ecursor  +  2 

•  len(foraal_para»eters. padding)  +  2; 
typespec.  padding  -  foraa  I  _paraaeters.  padding; 
where. bcursor  -  I en(where. Indent); 

where. padding  »  where. Indent; 
concept. strvalue  ■  foraa I _paraaeters. ecursor  <  0 
->  ["\n",  '\n“,  concept. Indent,  'CONCEPT  ",  NAME .Xtext, 

foraal_paraaeters.str_value,  "\n‘,  foraa l_paraaeters. padding,  *:  ", 
type_spec.str_value,  coaaent. str_va I ue,  where. strvalue] 

«  foraaI_paraaeters. ecursor  +  2  <-  80 
->  [*\n",~’\n“,  concept. Indent,  'CONCEPT  ",  NAME. Xt ext, 

foraa l_paraaeters.str_value,  ':  *,  type_spec.str_value,  comment. strvalue, 
where. st r  value] 

•  ["\n",  '\n“,  concept. Indent,  'CONCEPT  ',  NAME .Xtext , 

formal_parameters.str_value,  '\n',  forma  I _parameters. padding,  ":  ", 
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type  spec.str  value,  comment. str  value,  where. str  value]; 

} 

!  CONCEPT  NAME  forial_paraaeters  foraa l_arguaents  where  VALUE  foraal_arguaents  where 
I  functions 
{ 

foraal_paraaeters. Indent  »  [concept. Indent,  spaces(3)]; 
where [T], Indent  -  [concept. Indent,  spaces(3)]; 
wherei 2]. Indent  -  [concept. Indent,  spaces(3)]; 
foraa I _paraaeters. bcursor  «  concept. bcursor  +  8  +  len(NAME.Xtext); 
foraal_paraaeters. padding  -  [concept. padding,  spaces(8),  spaces ( len(NAME.Xtext))]; 
foraa I _arguaents[1], bcursor  «  forma l_paraaeters.ecursor  >  0 
->  foraa l_paraaeters.ecursor 
•  I en ( f oraa I _pa  r  aaeter s .padding); 
foraa l_arguaents[1]. padding  *  foraal_paraaeters.paddlng; 
where[T]. bcursor  -  len(where[1]. Indent); 
where[1]. padding  -  where [1]. Indent; 

foraa l _arguaents[2]. bcursor  -  len(concept. padding)  4-3  +  6; 
foraa l_arguaents[2] .padding  •  [concept. padding,  spaces(3),  spaces(6)]-, 
where[2]. bcursor  -  len(where[2]. Indent); 
where[2]. padding  -  where[2]. indent; 

concept. str  value  -  ["\n",  “\n",  concept. indent,  ‘CONCEPT  ”,  NAME. Xt ext, 
foraa  I  parameters  ,str_va  lue ,  f oraa  l_arguaents[  1  ]  .str  va  lue ,  where[  1  ]  .str  va  lue , 
"\n‘,  concept. Indent,  spaces(3),  "VALUE  ",  foraa l_arguaents[2].str_va lue, 
where[2].str  value]; 

} 


aodel  I  data  types  have  conceptual  aodels  for  values 

:  MODEL  foraa I  arguaents  Invariant 

{ 

Invar  1  ant. indent  -  [aodel . indent,  spaces(3)]; 
foraa I  arguments. bcursor  -  len(aodel . Indent)  +  6; 
forma  I  arguments. padding  »  [model . Indent,  spaces(6)]; 

Invariant. bcursor  -  len( invariant. Indent); 

Invariant. padding  -  Invariant. Indent; 

aodel ,str_value  -  ["\n“,  “\n",  model . Indent,  "MODEL  ",  formal_arguments.str_value. 
Invariant. str  value]; 

} 

I  MODEL  foraal_arguaents  Invariant  Initially 
l  initial ly  clause  specif les  automatic  variable  Initialization 
{ 

Invariant. Indent  «  [aodel . Indent,  spaces(3)]; 

Initial ly. Indent  •  [aodel . Indent,  spaces(3)]; 
foraa l _arguaents. bcursor  «  len(aode I . Indent)  ♦  6; 
foraa I _arguaents. padding  -  [aodel . Indent,  spaces(6)]; 

Invariant. bcursor  ■  len( Invar  I  ant. Indent); 

Invar i ant. padding  «  Invariant. indent; 

Initial ly. bcursor  «  len(lnltlal ly. Indent); 

Initial ly. padding  -  initial ly. Indent; 
aodel .st r_va lue  ■  ["\n",  "\n",  aodel . Indent,  "MODEL  ", 
foraa I _arguaents . str_va lue ,  I nvar I  ant . st r_va I ue ,  initial  I y . str_va lue]; 
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} 


state  I  Machines  have  conceptual  eodels  for  states 

:  STATE  foraal  arguments  Invariant  Initially 
{ 

Invar  I  ant. Indent  -  [state. Indent,  spaces(3)]; 

Initial ly. Indent  -  [state. Indent,  spaces(3)]; 
foraal_arguaents.bcursor  -  len(state. Indent)  +  6; 
foraa I  arguaents. padding  -  [state. Indent,  spaces(6)]; 

Invarlant.bcursor  -  len( Invar  I  ant. Indent); 

Invar  I  ant. padding  -  Invariant. Indent; 
initial ly.bcursor  -  len( Initial ly. Indent); 

Initial ly. padding  -  Initial ly. Indent; 

state. strvalue  ■  [“\n“,  "\n“,  state. Indent,  'STATE  ",  foraa l_arguments.str_value, 
Invar lant.str  value,  Initial ly.str  value]; 

} 


Invariant  I  Invariants  are  true  In  all  states 
:  INVARIANT  expression  list  coaaent 
{ 

expresslonl 1st. bcursor  »  Invarlant.bcursor  +  10; 
coaaent.  bcursor  •  express  I  onj  1st  .ecursor; 
express  I  on _l 1st. padding  -  [ Invar  I  ant. padding,  spaces (10)]; 
Invar lant.str  value  -  [*\n*.  Invariant. indent,  “INVARIANT”, 
expression!  1st.  str  value,  coaaent. str  value]; 

} 


Initially  I  Initial  conditions  are  true  only  at  the  beginning 
:  INITIALLY  expression  list  coaaent 

{ 

expression! 1st. bcursor  -  Initial ly.bcursor  +  10; 
coaaent. bcursor  ■  express lon_l 1st. ecursor; 
express  I on_l 1st. padding  «  [Initially. padding,  spaces(IO)]; 
Initial ly.str_value  ■  [*\n“,  initial ly. indent,  “INITIALLY  ", 
expression  1 1st. str  value,  coaaent. str  value]; 

} 


transactions 

:  transactions  transaction 

{ 

transact lons[2]. Indent  -  transact !ons[1]. Indent; 
transaction. Indent  -  transactlons[1], Indent; 
transact ions[2]. bcursor  -  transact  I ons[l]. bcursor; 
transact lons[2]. padding  •  transact lons[1]. padding; 
transact  1  on. bcursor  -  len(transact Ion. Indent); 
transact  I  on. padding  -  transaction. Indent; 

transact lons[1]. str  value  -  [transact lons[2] .str  value,  transaction. str  value]; 
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} 

I 

I 

{ 

transact  tons. str  value  -  ““; 

} 


transaction 

:  TRANSACTION  para*str  I  zed  naae  action  expression  co»ent  where 
{ 

coeeent .bcursor  -  actlon_expresslon.ecursor; 
where. Indent  =  [transaction. Indent,  spaces(3)]; 
paraeetrlzed_naee. bcursor  -  len(transact Ion. Indent)  +  12; 
paraeetr  Izednaee. padding  -  [transaction.  Indent,  spaces(12)]; 
act  I on_expr ess  ion. bcursor  -  paraeetr lzed_naae.ecursor  +  3  <■  80 
->  paraeetr  Izednaee.ecursor  +  3 

•  I en (paraaet  r I zed_naee . padd Ing) ; 

act  I on_expr ess  ion. padding  •  paraeetr lzed_naee. padding; 
where. bcursor  -  I en( where. Indent); 
where. padding  -  where. Indent; 

transact  ion. str  value  «  paraeetrlzed  naee.ecursor  +  3  <»  80 
->  [“\n“,  “\n“,  transaction. Indent,  “TRANSACTION  “, 

paraeetr  Izednaee.strvalue,  *  «  ",  actionexpresslon.strvalue, 
comment. str  value,  where. str_value] 

•  ["\n",  “\n",  transaction. indent,  “TRANSACTION  “, 

paraeetr lzed_name.str_value,  “  •“,  “\n“,  parametrlzed_name. padd ing, 
action  express  Ion. str  value,  coeeent. str  value,  whereTstrvalue]; 

) 

I 

I  Transactions  are  atoelc. 

I  The  where  clause  can  specify  tie ing  constraints. 
actlon_expression 

:  action  expression  coeeent  action  list  Xprec  SEMI  Isequence 

{ 

action_expresslon[1], length  •  act lon_expresslon[2]. length  +  2  +  comment. length 
+  action! 1st. length; 

comment. bcursor  -  actlon_expresslon[2].ecursor  +  2; 
act ion_expresslon[2]. bcursor  -  action  express  I on[1]. bcursor; 
actlon_expresslon[2].padding  -  act  Ion "express lon[l]. padd Ing; 
actlonl 1st .bcursor  -  comment. length  >  0 
->  I  en ( act  I  on  express  I  on[  1  ] . padd  I  ng ) 
t  actlon_expresslon[2].ecursor  ♦  2  <-  80 
->  actlon_expression[2].ecursor  +  2 

•  I  en(act lon_express I  on [ 1 ] .padding); 

act lon_l 1st. padd Ing  -  actlon_expresslon[2]. padding; 
actlon_expresslon[1].ecursor  -  actlonj Ist.ecursor; 
action_expresslon[1].str_value  -  coeeent. length  >  0 
->  [act!on_expresslon[2].str_value,  “;“,  coeeent. str_ value, 
actionj  lst.str_value] 
t  action  express  I  on[2]  .ecursor  +  2  <-  80 


—-a 


s 


1 
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->  [action _expresslon[2].str_value,  coasent.strvalue, 

actlonl lst.str_value] 

•  [actlon_expresslon[2].str_value,  “\n“,  coeeent.str  jalue, 
action  express  I on[1]. padding,  action  iist.str  value]; 

} 

!  action  list 
{ 

actlon_expresslon  length  -  act  I on_ 1 1st . length; 
act  ion _l  1st  .bcursor  -  act  ionexpresslon. bcursor; 
act  I on_ 1 1st .padding  -  actlon_expresslon. padding; 
actlon_expresslon.ecursor  -  actlon_l Ist.ecursor; 
action  expression. str  value  -  action  Iist.str  value; 

} 


actlonj  1st 

:  action  list  action  list  Xprec  STAR  I  parallel 

{ 

actlonj  1st [  1  ] .  length  -  actlonj  ist[2].  length  +  actlonj  1st [3].  length; 

action  l lst[2]. bcursor  -  act lon_ I lst[1]. bcursor; 

actlonj  i st [2] . padding  -  actlonj  I st [  1  ] . padding; 

action! I st [3]. bcursor  -  actlonj lst[2].ecursor; 

actlonj lst[3]. padding  «  act  Ion J ist[1 ]. padding; 

actlonj  ist[1].ecursor  -  actionj  lst[3].ecursor; 

action  I lst[1].str_value  -  [action  llst[2].str  value,  actlonj  lst[3].str_value]; 

} 

!  IF  alternatives  FI  I  choice 

{ 

action  l 1st. length  -  3  +  alternatives. length  +  3; 

alternatives. bcursor  -  act  I on_ 1 1st. bcursor  +  3  +  alternatives. length  <»  80 
->  action  1 1st. bcursor  +  3 

#  len(actlonl 1st. padding)  +  3; 

alternatives. padding  -  actlonj 1st .bcursor  +  3  +  alternatives. length  <•  80 
->  [actlonj  1st. padding,  spaces(3>] 

*  actlonj  1st. padding; 

act l on_ I Ist.ecursor  -  alternatlves.ecursor  +  3  <■  80 
->  alternat ives.ecursur  +  3 

#  len(alternatlves. padding)  +  2; 

actlonj  lst.str_value  -  (act lonj  1st. bcursor  +  3  +  alternat Ives,  length  <«  80) 

&&  (alternatlves.ecursor  i  3  <>  80) 

->  [“IF  alternatlves.str_value,  *  F I " 3 

•  (act lonj  1st. bcursor  ♦  3  ♦  alternatives. length  >  80) 

&&  (alternatlves.ecursor  t  3  <•  80) 

->  [’\n“,  actionj  1st. padding,  “IF  alternatlves.str jalue,  "  FI"] 

*  (action  1 1st. bcursor  ♦  3  ♦  alternatives. length  <«  80) 

&&  (alternatlves.ecursor  +  3  >  80) 

->  [’IF  *,  alternatlves.str_value,*\n",  alternat Ives. padding,  “FI”] 

#  [*\n*,  act ion_l 1st. padding,  ’IF  ’,  alternatlves.str_value,  "\n", 

alternat Ives. padding,  ’FI’]; 

} 

!  00  alternatives  00  I  repetition 
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{ 

act ion_ 1 1st. length  «  3  ♦  alternatives. length  4  3; 

alternatlves.bcursor  >  actlonj  Ist.bcursor  434  alternatives,  length  «  80 
->  act  I on_ I Ist.bcursor  4  3 

•  len(actlon_l 1st. padding)  4  3; 

alternatives. padding  -  act lon_ I  ist.bcursor  434  alternatives,  length  <«  80 
->  [act lon_l 1st .padding,  spaces(3>] 

«  actlonj  1st. padding; 

actlonj  ist.ecursor  -  alternatives. ecursor  4  3  <»  80 
->  alternatives. ecursor  4  3 

•  len(alternat Ives. padding)  4  2; 

action  I  ist.str_value  «  (act lonj  Ist.bcursor  434  alternatives,  length  <•  80) 
&&  (alternatives. ecursor  4  3  <-  80) 

->  [’DO  ",  alternatives.strvalue,  *  OD'] 

•  (act lonj  Ist.bcursor  434  alternatives,  length  >  80) 

&&  (alternatives. ecursor  4  3  <-  80) 

->  ['\n',  action  1 1st. padding,  'DO  ',  alternatives. str  value,  "  OD"] 

•  (action  I  Ist.bcursor  434  alternatives,  length  <  80) 

&&  (alternatives. ecursor  4  3  >  80) 

->  ['DO  ",  alternatives. str_value,'\n",  alternatives. padding,  "OD"] 

•  [“\n",  action  1 1st .padding,  'DO  alternatlves.str_value,  "\n“, 

alternatives. padding,  '00']; 

} 

I  parametrized  naee  I  a  noma  I  message 

{ 

action  1 1st. length  -  paranetrlzedjiame.  length; 
parametr  Izedname.bcursor  •  actlonj  Ist.bcursor; 
parametr  I zed  name. padding  »  actlonj  1st. padding; 
actlonj Ist.ecursor  -  paranetrlzedjiame. ecursor; 
action  1 1st. str  value  «  parametrized  name.str  value; 

} 

!  EXCEPTION  parametrized  name  I  an  exception  message 
( 

act lonj 1st. length  -  10  4  parametrlzed_name. length; 

parametrized  jiame.bcursor  »  act  lonj  ist.bcursor  4  10; 

parametr i zedjiame. padding  •  [actlonj  1st. padding,  spaces(lO)]; 

act  lonj  Ist.ecursor  •  parametr  I  zedjiame.  ecursor; 

action  1 1st. str  value  -  ["EXCEPTION  ",  parametr ized_name. str  value]; 

} 


alternatives 

:  alternatives  OR  guard  action  expression 
{ 

alternatlves[l].  length  -  alternatives^],  length  434  guard,  length 
4  actlon_expr ess  Ion. length; 
alternatives[2].bcursor  *  alternatlves[1].bcursor; 
alternatives^]. padding  >  alternatlves[1]. padding; 
guard. bcursor  -  alternatives^]. ecursor  4  3  <-  80 
->  alternatives^]. ecursor  4  3 
#  len(alternatives[1]. padding)  4  2; 
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guard. padding  -  alternativesfl]. padding; 
act lon_expresslon.bcursor  -  guard. ecursor; 
act lon_expresslon. padding  -  alternativesfl]. padding; 
alternativesfl]. ecursor  «  actlon_expresslon.ecursor; 
alternativesfl]. str_value  ■  alternatlvesf2].ecursor  +  3  <-  80 
->  falternatlve$f2].str_value,  '  !  ",  guard. str_value, 
act lon_express ion .str_va !ue] 

•  falternatlvesf2].str_value,  "\n“,  alternativesfl]. padding,  “J  ", 
guard. str  value,  action  express i on. str  value]; 

} 

i  guard  action  expression 

{ 

alternatives. length  -  guard. length  +  act  1  on _express Ion. length; 

guard. bcursor  •  alternatives.bcursor; 

guard. padding  >  alternatives. padding; 

act  ion  expression. bcursor  «  guard. ecursor; 

act l on_express ion. padding  -  alternatives. padding; 

alternatives. ecursor  »  act  I on_express ion. ecursor; 

alternatives. str  value  «  fguard.str  value,  action  expression. str  value]; 

) 


guard 

:  WHEN  expression  ARROW 

{ 

guard. length  -  5  +  expression. length  +  3; 
express  I  on. padding  -  spaces (express  Ion. bcursor); 
expression. bcursor  -  guard. bcursor  +  5; 
guard. strvalue  -  express  I  on. ecursor  +  3  «»  80 
->  f “WHEN  *,  express  I  on. str  value,  ’  ->“,  *\n“,  guard. padding] 

#  f“WHEN  ",  expression. strvalue,  "\n“,  expression. padding,  ”\r 

guard. padding]; 

guard. ecursor  ■  expression. ecursor  +  3  <»  80 
->  len(guard. padding) 

•  len(guard. padding)  +  2; 

) 

I 

I 

{ 

guard,  length  -  0; 

guard. ecursor  -  guard. bcursor; 

guard. str  value  - 

} 


teapora Is 

:  teaporals  temporal 

f 

teaporals[2]. Indent  ■  teaporalsf 1]. Indent; 
teapora I .  Indent  »  teapora I sfl] . Indent; 
teaporalsf 2]. bcursor  -  teaporaisfl]. bcursor; 
teaporalsf2], padding  -  teaporaisfl]. padding; 


I 


tenporal .bcursor  •  tenporais[1].bcursor; 
temporal .padding  •  teapora Is. padding; 

teaporals[1].str  value  «  [teapora ls[2].str  va lue, teapora I .str  value]; 

} 

I 

I 

{ 

teaporals.str  value  -  ""; 

} 


teapora I 

:  TEMPORAL  NAME  where  response 

{ 

where. Indent  -  [teapora I . Indent,  spaces(3)]; 
response. Indent  •  [teapora I . Indent,  spaces(3)]; 
where. bcursor  -  I en( where. Indent); 
where. padding  «  where. Indent; 
response. bcursor  «  len(response. Indent); 
response. padding  >  response. indent; 

temporal .strva lue  -  [“\n“,  “\n",  teapora  1 .  Indent,  "TEMPORAL  ",  NAME .Xtext , 
where. str  value,  response. str  value); 

} 

» 

I  Teapora!  events  are  trigged  at  absolute  tlaes, 

I  in  teras  of  the  local  clock  of  the  actor. 

I  The  "where"  describes  the  triggering  conditions 
I  in  teras  of  “TIME"  and  "PERIOD". 

foraal_paraaeters  I  paraaeter  values  are  determined  at  specification  tine 

:  field  list  where 

{ 

where. indent  -  forma  I  parameters. Indent; 
f ie I d_ 1 1st .bcursor  -  forma  I  parameters. bcursor  +  1  <  80 
->  forma  I  parameters. bcursor  +  1 

•  len(formai_parameter$. padding)  +  1; 

fleldl 1st. padding  »  [formal  parameters. padding,  spaces(l)]; 
where. bcursor  «  len(where. Indent); 
where. padding  »  where. Indent; 
formal_paraaeters.ecursor  «  where. ecursor  <  0 
->  where. ecursor 

•  where. ecursor  <-  where. bcursor 
->  fleldl 1st. ecursor  +  1 

#  where. ecursor; 

forma l_parameters.str_va lue  -  foraal_parameters. bcursor  +  1  <  80 
->  ["{",  f  leldj  ist.str_value,  "}*,  where. str_value] 

*  f\n",  foraal_parameters. padding,  "{",  f leld_l  1st .str_va lue , 

where. str  value]; 

} 

I 

I 

{ 

formal  parameters. ecursor  «  formal  parameters. bcursor; 


I 


I 


I 


I 
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formal  parameters. str  value  • 

} 


formal  arguments  I  arguments  are  evaluated  at  run-time 

:  “(*  field  list  ')'  comment 
{ 

comment. bcursor  «  f leld_l Ist.ecursor  +  1; 
field  1 1st. bcursor  -  forma  I _arguments. bcursor  +  1  <  80 
->  forma  I _arguments. bcursor  +  1 

•  len(formal_arguments. padding)  ♦  1; 

field  1 1 st. padding  -  [forma l_arguments. padding,  spaces(l)]; 
formaT_arguments.ecursor  »  comment. length  —  0 
->  fleldj Ist.ecursor  +  1 

•  -1; 

formal  arguments. str  value  »  forma l_arguaents. bcursor  +  1  <  80 
->  [”(*,  fleldj  1st. str_value,  ’)\  comment. str_value] 
e  [“\n“,  forma  I _arguaents. padding,  fleldj 1st. str_value, 
comment. str  value]; 

} 

i  comment 

{ 

comment. bcursor  »  forma  I _arguments. bcursor; 

forma I  arguments. ecursor  -  forma l_arguments. bcursor; 

formal  arguments. strvalue  «  comment. strva I ue; 


field  list 

: "field  list  field 

{ 

fleldj  lst[l],  length  -  fleldj  lst[2].  length  +  2  +  f  leid.  length; 
field  I  ist[2]. bcursor  «  fleldj  lst[  1  ] .  bcursor; 
fleld_l ist[2]. padding  -  fleld_l ist[1]. padding; 
field. bcursor  ■  field  I  lst[2].ecursor  +  2  <=  80 
->  fleld_l ist[2]. ocursor  +  2 
«  len(fleld_l lst[1] . padding); 
field. padding  -  fleldj  lst[1J.  padding; 
f  laid  I  lst[l].ecursor  «  field. ecursor; 
f 1 e l d_ l ist[1].str_value  «  f I e I d_ I lst[2]. ecursor  +  2  <«  80 
->  [field  I ist[2].str  value,  ",  ",  field. str  value] 

«  [f leld'l  lst[2].str~value,  ’\n*.  fleldj lst[1]. padding,  field.  str_value]; 

} 

i  field 

{ 

fleldj  1st.  length  «  field,  length; 
field. bcursor  «  fleldj  1st. bcursor; 
field. padding  •  fleldj  1st  .padding; 
fleldj  Ist.ecursor  •  field. ecursor; 
field  1 1st. str  value  «  field. str  value; 

) 
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field 

:  naee  list  type  spec 
{ 

fie  Id.  length  -  naeej  1st.  length  +  2  +  type_spec.  length; 
na«e_l Ist.bcursor  -  field. bcursor; 
naeej  I  st.  padding  -  field. padding; 

type_spec. bcursor  -  naeej Ist.ecursor  +  2  +  type_spec. length  <«  80 
->  naee_ I Ist.ecursor  +  2 

•  len(f laid. padding)  +  2; 
typespec. padding  -  f  leld.padding; 
f leld.ecursor  -  type_spec.ecursor; 

field. str_value  -  naeej  Ist.ecursor  +  2  +  type_spec.  length  <«  80 
-»  [naeej  lst.str_value,  ",  type_spec.str_value] 

•  [naee  list.str  value,  “\n",  f leld.padding,  ",  type  spec.str  value]; 

) 

i  'S'  NAME  ':'  type  spec 
{ 

field. length  «  1  +  len(NAME.Xtext)  +  3  ♦  type_spec. length; 
typespec. bcursor  -  f laid. bcursor  +  3  +  len(NAME.Xtext)  +  1 
+  type  spec.  length  <«  80 
->  f leld. bcursor  +  3  ♦  len(NAME.Xtext) 

•  len(f leld.padding)  +  3  +  len(NAME.Xtext); 
type  spec. padding  -  f  leld.padding; 

f leld.ecursor  «  type_spec.ecursor; 

f leld.strvalue  -  f leld. bcursor  +  3  +  len(NAME.Xtext)  +  1 
+  type  spec. length  <-  80 
->  ["$",  NAME .Xtext ,  ",  type_spec.str  value] 

»  ["\n",  f leld.padding,  "$",  NAME.Xtext, ”,  typespec.str  value],- 

I 

!  '?' 

{ 

field. length  -  1; 

f leld.ecursor  -  f leld. bcursor  +  1  <-  80 
->  f leld. bcursor  +  1 

•  len(f leld.padding)  +  1; 

field. str  value  «  f leld.bcursor+  1  <■  80 
->  ■?"  " 

t  [“\n”,  field. padding,  "?"]; 


typespec 

:  parametrized  naee  I  naee  of  a  data  type 

{ 

type_spec. length  •  paraaetrlzed_na«e. length; 
parametr lzed_na«te. bcursor  ■  type_spec. bcursor; 
paraeetr I zed  naee. padding  «  type  spec. padding-, 
type_spec.ecursor  ■  parametrized  naee.ecursor; 
type_spec.str_value  -  paraeetr lzed_na«e.str_value; 
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} 

TYPE  actual  parameters 

{ 

type  spec. length  -  4  +  actual _parameters. length; 
actua I _parameters. padding  •  type _spec. padding; 
actua f parameters. bcursor  -  type'spec. bcursor  +  4  <-  80 
->  type_$pec. bcursor  +  4 

•  len(type_spec. padding)  +  4  ; 

type  spec.ecursor  -  actua l_parameters.ecursor; 
type  spec.str  value  -  type_spec.bcursor  +  4  <■  80 
->[ 'TYPE’, 'actual  parameters. str_value] 

•  t'\n',  type  spec. padding,  'TYPE',  actual_parameters.str_value]; 

} 

FUNCTION  actual  parameters 

{ 

type  spec. length  »  8  +  actua I _parameters. length; 
actual  parameters. bcursor  »  type_spec.bcursor  +  8  <»  80 
->  typespec.  bcursor  +  8 

•  I  en(type_spec. padding)  +  8; 

actua I  parameters. padding  -  type_spec. padding; 
type  spec.ecursor  -  actua l_parameters.ecursor; 
type  spec.str  value  »  typespec. bcursor  +  8  <»  80 
->_['FUNCT ION" ,  actua l_parameters.str_value] 

t  [“\n“,  type  spec. padding,  'FUNCTION',  actual _paraneters.str_value]; 

} 

MACHINE  actual  parameters 

{ 

type  spec. length  ■  7  +  actua I  parameters. length; 
actua l  parameters. bcursor  -  type_spec. bcursor  +  7  <«  80 
->  typespec. bcursor  +  7 

•  I en(type_spec. padding)  +  7; 

actua I  parameters. padding  »  type_spec. padding; 
actual  parameters. ecursor  ■  actua l_parameters.ecursor; 
type  spec.str  value  -  type_spec. bcursor  +  7  <-  80 
->  [“MACHINE”,  actua!_parameters.str_value) 

•  [“\n\  type  spec. padding,  'MACHINE',  actual_parameters.str_value]; 

) 

ITERATOR  actual  parameters 

{ 

type  spec. length  «  8  +  actua I _parameters. length; 
actua l  parameters. bcursor  -  type_spec. bcursor  +  8  <«  80 
-»  type  spec. bcursor  +  8 

•  I en ( type _spec. padding)  +  8; 

actua l _parameters. padding  -  type_spec. padding; 
actua ("parameters. ecursor  -  actua l_parameters. ecursor; 
type  spec.str  value  -  type_spec. bcursor  +  8  <»  80 
I TERATOR " ,  actua I _parameters . st r_va I ue ] 

•  [’\n\  type  spec. padding,  'ITERATOR',  actual_parameters.str_value]; 

) 

i 

{ 
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type_spec. length  *  1; 

type_spec.ecursor  -  type_spec.bcursor  +  1  <«  80 
->  type_spec.bcur$or  +  1 

•  len(type_spec. padding)  +  1; 

type  epec.str  value  •  type  spec.bcursor  +  1  <-  80 

•  [“\n”,  type_spec. padding, 


naae  I let 

:  naae  list  NAME 
{ 

naae  I lst[1]. length  ■  naa8j  1st  [2].  length  +  len(NAME.Xtext); 
naae  1 1 st[2]. bcursor  -  na«e_l lst[1].bcursor; 
na«e_l lst[2], padding  •  na«e_l lst[1]. padding; 

naael 1st [1].ecursor  -  (naae_l lst[2].ecursor  +  len(NAME.Xtext)  +  1)  <-  80 
->  naae  I lst[2] .ecursor  +  Ten(NAME.Xtext)  +  1 

•  len(naae  I lst[1]. padding)  +  I en< NAME.Xtext)  +  1; 

naae  I lst[l).str_value  -  (naae_l lst[2]. ecursor  +  I en( NAME.Xtext)  +  1)  <-  80 
->  [naae  I lst[2].str_va!ue,  NAME.Xtext,  *  “] 

t  [naae  llst[2].str  value,  *\n'p  naae  I  lst[1]. padding,  NAME.Xtext,  "  "]; 

) 

!  NAME 

{ 

naae  1 1st. length  -  I en( NAME.Xtext); 

naae  1 1st. ecursor  -  (naae  1 1st .bcursor  +  len(NAME.Xtext)  +  1)  <-  80 
->  naae  1 1st. be ursor  +  Jen(NAME.Xtext)  +  1 

•  len(naae  1 1st. padding)  +  I en( NAME.Xtext)  *  1; 

naae  I Ist.str  value  -  (naae  1 1st. bcursor  +  len(NAME.Xtext)  +  1)  <-  80 
->~[NAME.Xtext,  spaces(l)] 

•  ["\n”,  naae_l  1st. padding,  NAME.Xtext,  spaces(l)]-, 


optlonaljiaae 

:  NAME  foraal  paraaeters 

{ 

optional  naae. length  «  optional  naae. ecursor  »«  foraal  paraaeters. bcursor 
->  0 
#  1; 

opt  Iona  I _naae. ecursor  «  foraal  jsaraaeters. ecursor; 
foraal jiaraaeters. Indent  -  opt?onal_naae. Indent; 

foraalparaaeters. bcursor  -  opt  I onaljiaae. bcursor  +  len(NAME.Xtext)  <  80 
->  opt  Iona  I _naae. bcursor  +  len(NAME.Xtext) 

•  len(optlonal_naae. padding)  +  len(NAME.Xtext); 

foraal  paraaeters.  padding  ■  [opt  Iona  I  _naae.  padding,  spacesden(NAME.Xtext))]; 
optlonal_naae.str_value  -  opt  Iona  I _naae. bcursor  +  len(NAME.Xtext)  <  80 
->  [NAME.Xtext,  foraal_paraaeters.str_value] 

#  f\n",  optlonal_naae. padding,  NAMETxtext,  foraal_paraaeters.str_value]; 


I 

I 


{ 

opt  Iona  I _naae. length  -  0; 

optional  naae.ecursor  «  opt lonal_na«e.bcursor; 

optlonaTnaae.str  value  - 

} 


paraaetr  I zed  naae 

:  NAME  actual  paraaetars 

{ 

paraaetr  I  zednaae.  length  -  len(NAME.Xtext)  +  actua I  paraaeters. length; 
actual  paraaeters. bcursor  -  (paraaetr lzed_naae.bcursor  +  len(NAME.Xtext))  <»  80 
->  paraaetr izednaae. bcursor  +  len(NAME.Xtext) 

•  len(paraaetrTzed_nane. padding)  +  len(NAME.Xtext); 
paraaetrlzed  naae.ecursor  ■  actua l_paraaeters.ecursor; 
actua l  paraaeters. padding  «  paraaetr I zed_naae. padding; 

paraaetrlzed  naae.str  value  «  (paraaetr lzed_naae. bcursor  +len(NAME.Xtext)  )  <«  80 
->  [NAME.Xtext,  actual _paraaeters.str_value] 

•  [*\n\  paraaetrlzed'naae.paddlng,  NAME.Xtext,  actual_parameters.str_value]; 


actual  paraaeters  I  paraaeter  values  are  deterained  at  specification  tine 

:  Tr  arg  list  '}* 

{ 

actua I  paraaeters. length  -  2  +  arg_ 1 1st. length; 
arg _l 1st .bcursor  ■  actua I ^paraaeters. bcursor  +  1  <  80 
->  actua l  paraaeters. bcursor  +  1 
t  len(actual_paraaeters. padding)  +  1; 
argl 1st. padding  ■  spaces(arg_l 1st. bcursor); 
actual  paraaeters. ecursor  «  arg  l Ist.ecursor  +  1; 
actual  paraaeters. str  value  »  actua l_paraaeters. bcursor  +  1  <  80 
->  argj  Ist.str  value,  *)’] 

•  [“\n",  actual  paraaeters. padding,  ’(',  argl Ist.strvalue, 

) 

|  Xprec  SEMI  I  Bust  have  a  lower  precedence  than 

{ 

actua I  paraaeters. length  «  0; 

actual_paraaeters. ecursor  •  actua l_paraaeters. bcursor; 
actual  paraaeters. str  value  - 


actual  arguaents  I  arguaents  are  evaluated  at  run-tlae 

:  T(*  arg  list  ')' 

( 

actua I  arguaents. length  •  2  +  arg_l 1st. length; 
arg_ 1 1st. bcursor  »  actua I _arguaents. bcursor  +  1  <  80 
->  actua I _arguaents .bcursor  +  1 
*  len(actual_arguaents. padding)  +  1; 
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arg  1 1st. padding  >  spaces(arg_l Ist.bcursor); 
actua I _argueents. ecursor  -  arg_l Ist.ecursor  +  1; 
actual  argu«ents.str_value  •  actua l_argu«ents. bcursor  +  1  <  80 
->  [“(“,  arg_l 1st .str_value,  ’)'] 

•  [“\n",  actual  arguments. padding,  *(*,  argj lst.str_value, 

) 

!  xprec  SEMI  I  aust  have  a  lower  precedence  than  '(' 

{ 

actua I _arguaents. length  -  0; 

actual  arguments. ecursor  -  actual_arguaents.bcursor; 
actual  arguaents.str  value  - 

} 


erg _l 1st 

arg  list  arg  Xprec  COMMA 

{ 

argj  lst[1].  length  -  arg  l  ist[2].  length  +  2  +  arg.  length; 
arg  1 1 st [2] .bcursor  -  arg_l lst[1].bcursor; 
arg  1 1st [2] . padding  •  argj  I st[l]. padding; 
argTbcursor  -  arg  I lst[2].ecursor  +  2  <-  80 
-»  arg  I  ist[2] .ecursor  +  2 
»  len(arg  I  lst[1]. padding); 
arg. padding  -  arg_l lst[1]. padding; 
arg  I  lst[1]. ecursor  -  arg. ecursor; 
arg  llst[1].str  value  -  argj  lst[2]. ecursor  +  2  <-  80 
->  [arg  llst[2].str  value?  *.  ",  arg.strvalue] 

«  [arg  l  lst[2].str_value,  \\  '\n',  arg  I  lst[1]. padding,  arg.str  value); 

) 

!  arg 

{ 

arg  l 1st. length  «  arg. length; 
arg. bcursor  -  arg  I  Ist.bcursor; 
arg. padding  »  arg_l 1st. padding; 
arg  I Ist.ecursor  -  arg. ecursor; 
arg  llst.str  value  -  arg.str  value; 

) 


:  expression 
{ 

arg. length  -  expression. length; 
express  I  on. bcursor  *  arg. bcursor; 
express  Ion. padding  -  arg. padding; 
arg. ecursor  -  express  I  on. ecursor; 
arg.str  value  »  express  I  on.  str  value; 

} 

1  pair 

{ 

arg. length  -  pair. length; 
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pair. bcursor  -  arg.bcursor; 
pair. padding  «  arg. padding; 
arg.ecursor  -  pair.ecursor; 
arg.str  value  •  palr.str  value; 

} 


express  I on_ 1 1st 

:  expression  list  coiaent  expression  Spree  COMMA 

{ 

expression! Ist[ 1 ] . length  -  express lonj ist[2]. length  +  2  +  coeeent. length 
+  expression. length; 
express  I  on. bcursor  -  coeeent. length  >  0 
->  len(expresslon_l lst[1]. padding) 

•  expression! 1st [2]. ecursor  +  2  ♦  expression. length  <•  80 
->  express  lonj  lst[2] . ecursor  +  2 

•  len(expresslon_l lst[1]. padding); 
coeeent. bcursor  -  express lon_ I lst[2]. ecursor  +1; 
express  I  on.  padding  -  expresslonj  1st  [1].  padding; 
expression! Ist[2]. bcursor  -  expresslon_l 1st [1 ] . bcursor; 
expresslonj lst[2]. padding  -  expression  1 1st [1]. padding; 
expression  1 1st [1]. ecursor  -  express  Ion. ecursor; 
expression  1 1st [l].str  value  -  coeeent. length  >  0 

->  [express lonj lst[2].str_value,  *,  ",  coeeent. str  value, 
express ! on_ I f  st [ 1 ] . padd 1 ng ,  express  I  on . st  r _va  l  ue  ] 

•  expresslonj  lst[2]. ecursor  +  2  +  expression,  length  <»  80 

->  [express lonj lst[2].str_value,  *,  coeeent. strva I ue,  expression. strvalue] 

•  [expresslonj lst[2].str_value,  "\n\  coeeent. str  value, 

expression  l  lst[1). padding,  express  I  on. str  value]; 

} 

!  expression 

{ 

expresslonj 1st. length  -  expression. length; 
express  I  on. bcursor  -  expresslonj 1st .bcursor; 
express l on. padding  -  express  I on_ 1 1st .padding; 
expresslonj 1st. ecursor  «  express  Ion. ecursor; 
expression  l 1st. str  value  -  expression. str  value; 

} 


expression 

:  quantifier  '('  field  list  restriction  BIND  expression  ')' 

{ 

express  I on[l], length  «  quantifier. length  +  2  +  fleldl ist. length 
♦  restriction. length  +  4  +  express lon[2].  length; 
quant  If  ler  .padding  -  expresslonj], padding; 
quantifier. bcursor  -  express  I on[1], bcursor; 
fieldj  Ist.  bcursor  -  quant  If  ler. ecursor  +  1; 
fleldj  Ist. padding  -  spaces(f  ieldj  Ist. bcursor); 
restrict  Ion. bcursor  -  fleldj Ist. ecursor  +  restriction. length  <«  80 
->  field  I Ist. ecursor 
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•  f  ieldj  ist.bcursor; 
restriction. padding  -  f  Ieldj  1st  .padding-, 

express lon[2].bcursor  «  restrlctlon.ecursor  +  4  +  express lon[2]. length  +  1  <•  80 
->  restrlctlon.ecursor  +  4 

•  len(restr let  Ion. padding)  +  3; 

express lon[2]. padding  -  restrlctlon.ecursor  +  4  +  express lon[2]. length  +  1  «  80 
->  field  1 1st. padding 

•  [restrict  Ion. padding, spaces (3)]; 
expresslon[1].ecursor  •  express  I on[2].ecursor  +  1; 
expresslon[1].str_value  -  (f Ieldj Ist.ecursor  +  restriction. length  <«  80) 

&&  (restrlctlon.ecursor  +  4  +  1  +  expression^],  length  <-  80) 

&&  (restriction. length  —  0) 

->  [quantifier. str_value,  "(",  f Ieldj lst.str_value,  restrlctlon.strvalue, 

*  expresslon[2].str_value,  ")"] 

•  (f Ieldj Ist.ecursor  +  restriction. length  <■  80) 

&&  (restrlctlon.ecursor  +  4  +  1  +  express lon[2]. length  <»  80) 

&&  (restriction. length  >  0) 

->  [quantlf ler.str_value,  “(',  f Ieldj ist.str_value,  "  restriction. strvalue, 
"  ::  ",  expression^]. strvalue,  ")*] 

•  (f  Ieldj  Ist.ecursor  +  restriction,  length  >  80) 

&&  (restrlctlon.ecursor  +  4  +  1  +  express lon[2]. length  <•  80) 

&&  (restriction. length  —  0) 

->  [quantlf ler.strvalue,  "(",  f Ieldj Ist.strvalue,  "\n",  fleldl 1st. padding, 
restrictlcn.str_value,  ",  express lon[2].str_va lue,  ")“] 
t  (field  I Ist.ecursor  *  restriction. length  >  80) 

&&  (restrlctlon.ecursor  +  4  +  1  +  expression^],  length  <-  80) 

&&  (restriction. length  »  0) 

->  [quantlf ler.strvalue,  "(*,  f leld_l ist.strvalue,  *\n",  f Ieldj 1st. padding, 
restriction. str  value,  "  ::  ",  express lon[2].str_value,  ”)"] 
t  (fleld_l Ist.ecursor  +  restrict  Ion. length  »  80) 

&&  (restrlctlon.ecursor  +  4  ♦  1  ♦  express lon[2]. length  >  80) 

&&  (restriction. length  >  0) 

->  [quantlf ler.str  value,  "(",  fleld_l Ist.str _va I ue ,  "\n*.  f Ieldj  1st. padding, 
restriction. strvalue,  ’\n’, restriction. padding, :  ", 
express lon[2].str_value,  *)"] 

•  (field  I Ist.ecursor  +  restriction. length  >  80) 

(restrlctlon.ecursor  +  4  +  1  +  express ion[2]. length  >  80) 

&&  (restriction. length  »  0) 

->  [quantlf ler.str_value,  "(",  f Ieldj  1st. str_value,  "\n", 
restriction. padding,"::  ",  express lon[2].str_value,  ")"] 

•  restriction. length  —  0 

->  [quantlf ler.strvalue,  "(",  f le ld_l 1st .str_va lue,  restrlctlon.strvalue, 

"\n",  restriction. padding,  "::  ",  express lon[2].str_va lue,  ")"] 

•  [quantlf ler.strvalue,  "(",  f leld_l 1st .str_va lue,  "  ",  restriction. strvalue, 
"\n",  restrict  Ion. padding,  "::  ",  express lon[2].str  value,  ')"]; 

} 

!  paraeetrlzed  naie  actual  arguients 

{ 

expression. length  -  paraeetr I  zed  naae. length  +  actua I  arguaents. length; 
paraaetrizednaae.bcursor  -  express  I  on. bcursor-, 
paraeetr  I zed  naae. padding  -  expression. padding-, 


actua I _arguments. bcursor  «  parametrtzed_name. ecursor; 
actua I _argu»ents. padding  -  expression. padding; 
express  I  on. ecursor  -  actua I  arguments. ecursor; 

express  I on. st r  value  -  [parametrized  name. str  value,  actual  arguments. str  value]; 

} 

|  parametrized  naae  parametrized  name  actual  arguments 

{ 

expression. length  -  parametr I  zed _name[1]. length  +  1  +  parametrlzed_name[2]. length 
+  actua l_arguaents. length; 
parametrized _name[1].bcursor  -  expression. bcursor; 
parametr lzed_naae[1]. padding  «  express  I  on. padding; 
parametr lzed_name[2]. bcursor  -  parametr lzed_name[1], ecursor  +  1  <-  80 
->  parametr I zed_name[l]. ecursor  +  1 

•  Ien(parametr7zed_name[l]. padding)  ♦  1; 
parametr lzed_name[2]. padding  -  express  Ion. padding; 
actua l_arguments. bcursor  •  parametr I zed_name[2], ecursor; 
actual_arguments. padding  -  express  I  on.  padding; 
expression. ecursor  ■  actua I _arguments. ecursor; 

express  Ion. str_value  -  parametr lzed_name[1]. ecursor  +  1  <-  80 
->  [parametr7zed_name[1].str_value,  *•*,  parametrlzed_name[2].str_value, 
actua l_arguments .str_va lue] 

•  [parametrlzed_name[1].str_value,‘\n‘,  parametr  izednamefl], padding, 
parametr ized_name[2]. str  value,  actual  arguments. str  value]; 

} 

|  NOT  expression  Xprec  NOT 

{ 

express  I on[1]. length  -  1  +  express lon[2]. length; 

express lon[2]. bcursor  -  express lon[1]. bcursor  +  1  ♦  express  I on[2]. length  <«  80 
->  express lon[1]. bcursor  +  1 

•  len(expresslon[1]. padding)  +1; 
expression^]. padding  ■  [express lon[1]. padding,  *  *]; 
express l on[l]. ecursor  -  express lon[2]. ecursor; 

expresslon[1].str_value  -  express lon[1]. bcursor  +  1  +  express lon[2]. length  <•  80 
->  [*"*,  express lon[2].str_va lue] 

•  f"\n",  expresslonfl]. padding,  *'*,  expresslon[2].str_value]; 

} 

I  expression  AND  expression  Xprec  AND 
{ 

express  I on[1]. length  -  express lon[2]. length  +  3  +  express  I on[3] . length; 
expression^]. bcursor  -  express  I  on[1].  bcursor; 
expression^], padding  -  expresslonfl]. padding; 

express lon[3]. bcursor  -  express lon[2]. ecursor  +  3  +  express lon[3]. length  <»  80 
->  express  I on[2]. ecursor  +  3 

•  len(expresslon[1], padding)  +  2; 
expression^]. padding  -  expresslonfl]. padding; 
expresslonfl]. ecursor  -  express  I on[3]. ecursor; 

express lon[1].str_va lue  -  express lon[2]. ecursor  +  3  +  express lon[3], length  <«  80 
->  [express ion[2].str_va lue,  “  &  ",  expression^]. str_va lue] 

•  [expres8lon[2].str_value,  "\n",  expresslonfl]. padding,  ”&  *, 

express lon[3]. str  value]; 

} 
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i  expression  OR  expression  Spree  OR 
{ 

express lon[1].  length  «  expression^],  length  +  3  +  expression^].  length; 
express lon[2].bcursor  -  express  I on[1].bcursor; 
express lon[2] .padding  •  express lon[1]. padding; 

express lon[3].bcursor  -  express lon[2].ecursor  +  3  +  express ion[3], length  <•  80 
->  express  I on[2].ecursor  +  3 
«  len(expresslon[1]. padding)  +  2; 
express ion[3]. padding  -  express  I on[1]. padding; 
express lon[1].ecursor  -  express  I on[3].ecursor; 

expresslon[1].str_value  -  express lon[2].ecursor  +  3  ♦  express lon[3]. length  <«  80 
->  [express  I on[2].str_va lue,  *  |  *,  expression^]. str_value] 

•  [ express lon[2].str_va lue,  "\n",  express  I on[l]. padding,  *}  ", 

express lon[3].str  value]; 

) 

!  expression  IMPLIES  expression  Spree  IMPLIES 

( 

expresslon[1].  length  -  express lon[2].  length  4  4  +  expression^] .  length; 
express i on[2].bcursor  -  express lon[1].bcursor; 
express i on [2]. padding  •  express lonC 1 ] . padding; 

express ion[3].bcursor  -  express lon[2].ecursor  +  4  +  express  I on[3] . length  <-  80 
->  express lon[2].ecursor  +  4 

•  len(expresslon[1]. padding)  +  3; 
expression^]. padding  -  express  I  on[1].  padding; 
express lon[1].ecursor  -  express  I on[3].ecursor; 

express lon[l].str_va lue  -  express lon[2].ecursor  +  4  +  express l on[3] . length  <»  80 
->  [express  I on[2].str_va lue,  "  ->  ",  express ion[3].str_va lue] 

•  [expression^]. str_value,  "\n",  express lon[1], padding,  "«>  ", 

express lon[3] .strva lue] ; 

} 

I  expression  IFF  expression  Xprec  IFF 
{ 

express  I on[1], length  -  express ion[2]. length  +  5  +  express lon[3] .  length; 
express lon[2].bcursor  -  express  I on[1].bcursor; 
expression^]. padding  ■  express  I  on[1J.  padding; 

express lon[3].bcursor  -  express lon[2].ecursor  +  5  +  expression^].  length  «  80 
->  express lon[2].ecursor  +  5 

•  len(expresslon[1]. padding)  ♦  4; 
expression^]. padding  -  spaces(expresslon[3].bcursor); 
express l on[l].ecursor  -  expression^]. ecursor; 

expresslon[1].str_value  -  express lon[2].ecursor  +  5  +  express  I on[3]. length  <«  80 
->  [ express lon[2].str_va lue,  ’  «■>  ",  express lon[3].str_va lue] 

•  [express lon[2].str_va lue,  "\n",  express  I on[l]. padding,  "<»>  ", 
express lon[3].str  value]; 

} 

I  expression  '<'  expression  Xprec  LE 
( 

express  I  on[1].  length  ■  expression^].  length  +  3  +  express  1  on[3] .  length; 
express lon[2].bcursor  »  express lon[l].bcursor; 
express lon[2] .padding  •  express  I on[1]. padding; 

express lon[3].bcursor  -  express lon[2].ecursor  +  3  +  express lon[3], length  <»  80 


149 


->  express  I on[2].ecursor  +  3 

•  I en (express  I on[1]. padding)  +  2; 
expression^]. padding  -  express  I  on[1].  padding; 
express  I on[1].ecursor  -  express lon[3].ecursor; 

express lon[1].str_value  ■  express lon[2].ecursor  +  3  +  expression^] .  length  <-  80 
-»  [express lon[2].str_value,  *  <  ",  express ion[3].str_value] 

•  [expresslon[2].str_value,  '\n*,  express lon[1]. padding,  *<  ", 

express lon[3].str  value]; 

} 

I  expression  *>*  expression  Xprec  LE 
( 

express  I on[1]. length  -  express lon[2]. length  +  3  +  express lon[3]. length; 
express  I on[2].bcursor  -  express lon[1].bcursor; 
express lon[2]. padding  -  express  I on[1]. padding; 

express  lon[3].bcursor  -  express  I on[2].ecursor  +  3  +  express lon[3]. length  <«  80 
->  express lon[2].ecursor  +  3 
t  len(expresslon[1].paddlng)  +  2; 
expression^]. padding  -  express  I  on[1].  padding; 
express  I on[1].ecursor  -  express lon[3].ecursor; 

expresslon[1].str_value  -  express lon[2].ecursor  +  3  +  express lon[3] . length  <•  80 
->  [expresslon[2].str_value,  “  >  ",  expression^]. strvalue] 

•  [expression^]. str_value,  *\n",  expresslon[1], padding,  ">  ", 

express lon[3].str  value]; 

} 

I  expression  *-*  expression  Xprec  LE 
{ 

express  I on[1]. length  -  express lon[2] . length  +  3  +  express ion[3]. length; 
express  I on[2].bcursor  -  express lon[1].bcursor; 
express lon[2]. padding  -  expression!!]. padding; 

express lon[3].bcursor  -  express lon[2].ecursor  +  3  +  expression^],  length  <«  80 
->  express ion[2].ecursor  +  3 

•  len(expresslon[1]. padding)  +  2; 
expression^]. padding  -  expression!!]. padding; 
expresslon[1].ecursor  -  express lon[3].ecursor; 

expression[l].str_value  ■  express lon[2].ecursor  +  3  +  express lon[3]. length  <«  80 
->  [express lon[2].str_value,  "  -  express lon[3].str_value] 

•  [expression^]. str_value,  "\n",  express lon[1]. padding,  ", 

express lon[3].str  value]; 

} 

I  expression  LE  expression  Xprec  LE 
{ 

express  I  on[1].  length  -  expression^],  length  +  4  +  expresslon[3] .  length; 
expresslon[2].bcursor  -  express  I on[l].bcursor; 
express lon[2]. padding  ■  express  I on[1]. padding; 

express lon[3].bcursor  •  express lon[2].ecursor  +  4  +  expression^] .  length  <-  80 
->  express lon[2].ecursor  ♦  4 

•  len(expresslon[1]. padding)  ♦  3; 
express ion[3] . padding  -  express  I on[ 1 ] . padding; 
expresslon[1].ecursor  -  expresslon[3].ecursor; 

expresslon[1].str_value  -  express lon[2].ecursor  +  4  ♦  express lon[3]. length  <»  80 
->  [express lon[2].str  value,  "  <-  ",  express icn[3].str  value] 
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•  [expression^]. str_value,  "\n",  express  I  on[1].  padding,  "<• 

expresston[3].str  value]; 

) 

I  expression  GE  expression  Xprec  LE 

{ 

express  I on[1]. length  -  express lon[2]. length  +  4  +  express ion[3]. length; 
express lon[2].bcursor  «  express  I on[1].bcursor; 
express ion[2]. padding  -  express lon[1]. padding; 

express  I on[3].bcursor  ■  express lon[2].ecursor  +  4  +  express lon[3]. length  <«  80 
->  express lon[2].ecursor  +  4 

•  len(expresslon[1]. padding)  ♦  3; 
expression^]. padding  -  express lon[1]. padding; 
express  I  on  [1].ecursor  ■  expression^]. ecursor; 

express  I on[1].str  value  -  express lon[2].ecursor  ♦  4  +  express lon[3]. length  <•  80 
->  [express lon[2].str_value,  *  >-  expresslon[3].str_value] 

«  [express lon[2].str_value,  “\n",  express lon[1]. padding,  ">» 
express lon[3].str  value]; 

) 

I  expression  NE  expression  Xprec  LE 
{ 

express i on[1]. length  -  express ion[2]. length  +  4  +  express lon[3]. length; 
express lon[2].bcursor  »  express  I on[1].bcursor; 
expression^]. padding  -  express  I on[1]. padding; 

express lon[3].bcursor  -  express lon[2].ecursor  +  4  +  express lon[3], length  <•  80 
->  express lon[2].ecursor  +  4 

•  len(express!on[1]. padding)  ♦  3; 
expression^]. padding  -  express  I  on[1].  padding; 
express  I on[1].ecursor  «  express lon[3].ecursor; 

expression[1].str_value  ■  express ion[2].ecursor  +  4  +  expression^] .  length  <«  80 
->  [express ion[2].str_value,  ‘  ",  expresslon[3].str_va!ue] 

•  [expression^]. strvalue,  "\n",  express lon[1] .padding,  ", 

express lon[3].str  value]; 

} 

!  expression  NLT  expression  Xprec  LE 

{ 

express lon[l].  length  «  express lon[2].  length  +  4  +  expression^],  length; 
express lon[2].bcursor  «  expresslon[1].bcursor; 
express lon[2]. padding  -  express ion[1]. padding; 

express lon[3].bcursor  -  expression^]. ecursor  +  4  +  expression[3], length  <=  80 
->  express lon[2].ecursor  +  4 

•  len(expresslon[1]. padding)  ♦  3; 
expression^]. padding  -  expression[1]. padding; 
express lon[1].ecursor  -  expression^]. ecursor; 

expresslon[1].str  value  -  expresslon[2].ecursor  +  4  +  express lon[3]. length  <=  80 
->  [expresslon[2].str_value,  "  "<  ",  expresslon[3] .str_value] 

•  [express lon[2].str_value,  "\n",  expresslon[1], padding,  "*<  ", 

express ion[3].str  value]; 

} 

i  expression  NGT  expression  Xprec  LE 
{ 

express lon[1].  length  *  expression^].  length  +  4  +  express lon[3].  length; 
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express ion[2].bcursor  -  express ion[1].bcursor; 
expression^], padding  -  expression^ . padding; 

express  I on[3].bcursor  -  express lon[2].ecursor  +  4  +  express lon[3]. length  <-  80 
->  express lon[ 2]. ecursor  +  4 

•  len(expresslon[1]. padding)  +  3; 
express lon[3]. padding  -  expresslon[l]. padding; 
expre'sion[1], ecursor  •  express lon[3].ecursor; 

express lon[1].str_value  -  express ion[2].ecursor  +  4  +  express lon[3]. length  <-  80 
->  [express lon[2].str_va lue,  "  ">  *,  express lon[3].str_value] 

•  [expresslon[2].str_value,  *\n",  express lon[l], padding,  ’">  *, 

express  I on[3] . st r~va I ue] ; 

) 

expression  NLE  expression  Xprec  LE 
{ 

express  I  on[1].  length  -  express  lon[2].  length  +  5  +  expression^].  length; 
express  I on[2].bcursor  -  expresslon[l].bcursor; 
express  I on[2]. padding  -  expresslon[1]. padding; 

express lon[3].bcursor  •  express lon[2].ecursor  +  5  +  express lon[3]. length  <«  80 
->  express ion[2].ecursor  +  5 

•  len(expresslon[1]. padding)  +  4; 
express lon[3], padding  -  express lon[l], padding; 
express ion[1].ecursor  -  express lon[3].ecursor; 

expression[1].str_value  -  express lon[2].ecursor  +  5  *  express lon[3]. length  <«  80 
->  [express  I on[2].str_va lue.  “  ",  express ion[3].str  value] 

•  [express lon[2].str_va lue,  "\n",  express lon[1], padding,  "'<»  ", 

express ion[3] . str'va lue] ; 

) 

expression  NGE  expression  Xprec  LE 
{ 

express lon[1]. length  -  express lon[2]. length  +  5  +  express ion[3]. length; 
express lon[2].bcursor  -  express lon[ I J.bcursor; 
express lon[2], padding  -  express lon[l]. padding; 

express ion[3].bcursor  ■  express lon[2].ecursor  +  5  +  expresslon[3] . length  <«  80 
->  express lon[2].ecursor  +  5 

•  len(expresslon[l], padding)  +  4; 
express lon[3]. padding  -  express  I on[l], padding; 
express lon[1].ecursor  -  expression^]. ecursor; 

express  I on[1].str_va lue  -  express lon[2].ecursor  +  5  +  express  lon[3].  length  <-  80 
->  [expresslon[2].str_value,  *  ">»  ",  express lon[3].str_va lue] 

•  [expression^]. str’value,  "\n",  express lon[l]. padding,  ", 
express  I on [ 3] . st r "va 1 ue ] ; 

) 

expression  EQV  expression  Xprec  LE 
{ 

express  I on[1]. length  -  express lon[2], length  +  4  +  express lon[3]. length; 
express lon[2].bcursor  •  expresslon[l].bcursor; 
expression^],  padding  -  express  I  on[l],  padding; 

express  I  on [3 J.bcursor  -  expresslon[2].ecursor  +  4  +  express ion[3J. length  <-  80 
->  expression^]. ecursor  +  4 

•  len(expresslon[1], padding)  +  3; 
express ion[3]. padding  -  express  I on[ 1 ] . padding; 
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expresslon[1].ecursor  *  expression^]. ecursor; 
expresslon[1].str_value  «  express lon[2].ecursor  +  4  +  expression[3]. length  <«  80 
->  [express lon[2] .str_value,  “  —  ",  express lon[3] .str_value] 

•  [express I on[ 2] .str_value,  ”\n”,  expresslon[1] .padding,  ",  I 

expresslon[3] .str  value]; 

} 

!  expression  NEQV  expression  Spree  LE 
{ 

express  I  on[  1  ] .  length  -  express  1  on[2] .  length  +  5  +  expression^],  length; 

express lon[2].bcursor  •  express lon[1].bcursor;  | 

express lon[2]. padding  «  expresslon[l]. padding; 

express  I on[3].bcursor  «  express  I on[2].ecursor  +  5  +  express lon[3]. length  <-  80 
->  express lon[2].ecursor  +  5 

•  len(expresslon[l] .padding)  ♦  4; 
express lon[3]. padding  •  express lon[l]. padding; 

expresslon[1].ecursor  «  expression^]. ecursor;  I 

expresslon[1].str_value  »  expression^]. ecursor  +  5  +  express lon[3].  length  <=  80 
-»  [express ion[2] .strvalue,  *  '•»  ”,  express lon[3].str_value] 

•  [expresslon[2].str_value,  ”\n",  express lon[1]. padding,  "'•«  ", 

express lon[3] .strvalue]; 

} 

i  expression  Spree  UMINUS  I 

{ 

express  I on[1], length  -  1  +  express lon[2]. length; 

express ion[2].bcursor  -  express  I on[1]. bcursor  +  1  +  express lon[2]. length  <=  80 
->  expression[1] .bcursor  +  1 

•  len(expresslon[1], padding)  +  1; 

expression^]. padding  «  express lon[l]. padding;  ! 

expresslon[1].ecursor  -  express lon[2].ecursor; 

express  I  on[1].str_value  -  express  I  on[1].  bcursor  +  1  +  express  I  on  [  2  ] .  length  <«=  80 
->  [“-’,  express lon[2].str_value] 

•  ["\n“,  expresslon[1], padding,  express lon[2], str  value]; 

} 

i  expression  '+'  expression  Spree  PLUS  i 

{ 

express lon[1 ]. length  «  express lon[2]. length  +  3  +  express lon[3] . length; 
express ion[2]. bcursor  -  expresslon[1] .bcursor; 
expression^]. padding  ■  expresslon[1]. padding; 

express lon[3]. bcursor  ■  express ion[2].ecursor  +  3  +  express  I on[ 3] . length  <=  80 
->  express lon[2].ecursor  +  3 

•  len(expresslon[1). padding)  *■  2; 
expression^]. padding  >  expresslon[1]. padding; 
express lon[1].ecursor  -  express lon[3].ecursor; 

expresslon[1].str_value  -  express lon[2].ecursor  +  3  +  express lon[3].  length  <•  80 
->  [expresslon[2].str_value,  “  +  ”,  express lon[3].str_value] 

•  [express ion[2].str_value,  "\n”,  express  I on[1]. padding,  "+  ”, 

express lon[3] .str  value]; 

} 

I  expression  expression  Spree  MINUS 
{ 

express  I on[ 1 ] . length  »  express lon[2]. length  +  3  +  express lon[3]. length; 
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express ion[2] .bcursor  «  express lon[!]. bcursor; 
express lon[2]. padding  «  express  I on[l]. padding; 

express  I  on[  3].  bcursor  ■  expression! 2]. ecursor  +  3  +  expression^].  length  <«  80 
express lon[2].ecursor  +  3 

•  len(expresslon[1], padding)  +  2; 
expresslon[3]. padding  *  expresslon[1]. padding-, 
expresslon[l].ecursor  -  express lon[3] .ecursor; 

expresslon[l].str  value  «  expresslon[2]. ecursor  +  3  +  express lon[3] . length  <=  80 
->  [expresslon[2].str_va!ue,  “  -  expression^]. str_value] 

•  [express lon[2] .str_va lue,  "\n",  express lon[1]. padding,  ", 

express lon[3] ,str_value]; 

} 

expression  expression  >  Xprec  MUL 

{ 

expresslon[1].  length  -  express lon[2].  length  +  3  +  expression^] .  length; 
express lon[2]. bcursor  -  expresslon[1]. bcursor; 
expression^], padding  «  express lon[1]. padding; 

express lon[3]. bcursor  «  express ion[2]. ecursor  +  3  +  expression^] .  length  <=  80 
->  express lon[2]. ecursor  t  3 

•  len(expresslon[1], padding)  +  2; 
expression! 3]. padding  -  expression!!], padding; 
expresslontl]. ecursor  «  express  I  on [ 3 ] . ecursor; 

expresslon[1].str  value  -  express lon[2]. ecursor  +  3  +  express lon[3].  length  <«  80 
->  [express  I on[2].str_va lue,  '  *  ",  express lon[3].str_va lue] 

•  [express lon[2].str_va lue,  *\n",  express lon[l], padding,  "*  ", 

express lon[3] .str_va lue] ; 

} 

expression  '/'  expression  Xprec  01 V 
{ 

express  I on[1]. length  «  express ion[2] . length  +  3  +  expresslon[3] . length; 
express lon[2] .bcursor  «  expression!!]. bcursor; 
expression^].  padding  •  express  I  on[1].  padding; 

express ion[3]. bcursor  «  expresslon[2]. ecursor  +  3  +  express  I on[3] . length  <«  80 
->  express lon[2] .ecursor  +  3 

•  len(expresslon[1], padding)  ♦  2; 
express lon[3] . padding  -  express ion[1]. padding; 
express  I on[1], ecursor  -  express lon[3] .ecursor; 

expresslon[l].str  value  -  expression^]. ecursor  +  3  +  expression[3].  length  <=  80 
->  [expression[2].str_value,  ‘  /  ’,  express ion[3] .str_va lue] 

«  [expresslon[2].str_value,  "\n’,  expression!!]. padding,  "/  ", 
expresslon[3].str  value]; 

} 

expression  MOO  expression  Xprec  MOD 

{ 

expression!!] .  length  «  expresslon[2]. length  +  5  +  expression[3] .  length; 
express lon[2] .bcursor  ■  expression!!]. bcursor; 
express lon[2] . padding  -  expression!!]. padding; 

expresslon[3].bcursor  •  express lon[2]  .ecursor  +  5  +  express  I on[ 3] . length  <=  80 
->  express lon[2]. ecursor  +  5 

•  len(expresslon[l] .padding)  +  4; 
expresslon[3].paddlng  -  expression!!]. padding; 
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express  I on[1]. ecursor  -  express ion[3].ecursor; 

expresslon[1].str_value  -  expressfon[2]. ecursor  +  5  +  express  I on[3] . length  <»  80 
->  [express lon[2] .str_value,  "MOO  ",  express len[3].str_value] 

*  [express lon[2].str_value,  "\n“,  express ion[1], padding,  "MOD  M, 

express lon[3].str  value]; 

} 

expression  EXP  expression  Spree  EXP 
{ 

express  lon[1].  length  -  express  I  on[2].  length  +  4  +  expression^].  length; 
express ion[2].bcursor  -  expresslon[1].bcursor; 
expression^], padding  -  express lon[1], padding; 

express ion[3].bcursor  -  express ion[2].ecursor  +  4  +  expression^],  length  <•  80 
->  express lon[2].ecursor  +  4 

•  len(expresslon[1]. padding)  +  3; 
express  I on[3]. padding  •  express lon[1]. padding; 
express lon[1].ecursor  «  express lon[3].ecursor; 

expresslon[1].str_value  •  express lon[2].ecursor  +  4  +  express lon[3].  length  <•  80 
->  [express lon[2] .str_value,  *  *•  ",  express lon[3].str_value] 

#  [expresslon[2].str_value,  "\n“,  express lon[1], padding,  "•*  ", 

express lon[3].str  value]; 

} 

expression  U  expression  Spree  U 

{ 

express  I  on[ 1 ] .  length  -  express  I on[2]. length  +  3  +  expression[3] . length; 
express  I on[2].bcursor  ■  express  I on[1].bcursor; 
express ion[2]. padding  >  express  I on[1]  .padding; 

express lon[3].bcursor  «  express lon[2].ecursor  +  3  ♦  express lon[3], length  <«  80 
-»  express ion[2].ecursor  +  3 

#  len(expresslon[1], padding)  ♦  2; 
expression^],  padding  -  express  I  on[1].  padding; 
expresslon[1].ecursor  «  express lon[3].ecursor; 

expresslon[1].str_value  »  express lon[2] .ecursor  +  3  +  expression^] .  length  <-  80 
->  [express ion[2].str_value,  "  U  ",  express lon[3].str_value] 

«  [expression^]. strvalue,  "\n",  expresslon[1]. padding,  "U  ", 
expression[3] .str  value]; 

) 

expression  APPEND  expression  Xprec  APPEND 

{ 

express  I  on[1],  length  «  expression^].  length  +  4  +  express  I  on[  3].  length; 
express lon[2].bcursor  -  expresslon[1].bcursor; 
express lon[2]. padding  «  express lon[1]. padding; 

express lon[3] .bcursor  -  express lon[2]. ecursor  +  4  +  express lon[3]. length  <-  80 
->  express ion[2]. ecursor  +  4 

•  len(expresslon[1], padding)  +  3; 
express lon[3] .padding  •  express lon[1]. padding; 
express l on[l], ecursor  -  express lon[3]. ecursor; 

expresslon[l].str_va!ue  «  express lon[2]. ecursor  +  4  +  express ion[3]. length  <-  80 
->  [express lon[2].str_value,  *  J!  ",  expresslon[3].str_value] 

*  [expression^]. str_value,  "\n",  express lon[  1  ] . padding,  "!!  ", 

expression^]. str  value]; 

} 
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!  expression  IN  expression  Spree  IN 
{ 

express ion[1].  length  -  express lon[2].  length  +  4  +  expression^].  length; 
express  I  on[2].bcursor  «  express lon[1] .bcursor; 
express lon[2]. padding  «  express lon[1], padding; 

express ion[3]. bcursor  -  express lon[2].ecursor  +  4  +  express lon[3], length  <«  80 
->  express  I on[2].ecursor  +  4 

•  len(expresslon[l], padding)  +  3; 
expression^], padding  «  expresslon[1J.  padding-, 
express  I on[1].ecursor  ■  express ion[3].ecursor; 

expresslon[1].str_value  -  express ion[2].ecursor  +  4  +  express lon[3], length  <•  80 
->  [express ton[2].str_va lue,  '  IN  *,  express lon[3].str  value] 

#  [expresslon[2].str_value,  "\n\  express lon[1]. padding,  'IN  “, 

express lon[3] .str~va lue] ; 

} 

I  expression  jprec  STAR 

I  *x  Is  the  value  of  x  before  a  transition 
I  x  Is  the  value  after  the  transition 
{ 

express  I on[l], length  »  1  +  exp. ess lon[2]. length; 

express  I  on [ 2 ]  .bcursor  -  express lon[1]. bcursor  +  1  +  express lon[2] .  length  <-  80 
->  express  I on[1], bcursor  +  1 

#  len(expresslon[1], padding)  +  1; 
express  I on[ 2]. padding  -  express  I on[1], padding; 
expresslon[l].ecursor  «  expression^]. ecursor-, 

express  I on[1].str_va lue  -  express lon[1]. bcursor  +  1  +  express  I on[2], length  <«  80 
->  ["•*,  express lon[2].str_va lue] 

*  C”\n',  expression^, padding,  *•*,  expresslon[2].str  value]; 

} 

!  't'  expression  Xprec  DOT 

I  $x  represents  a  collection  of  I  teas  rather  than  just  one 
I  si  -  {x,  $s2)  aeans  si  -  unlon({x),  s2) 

I  si  -  [x,  $s2]  Beans  si  -  append([x],  s2) 

{ 

expresslon[1]. length  »  1  +  express lon[2J. length; 

express lon[2]. bcursor  «  express lon[1]. bcursor  +  1  +  express lon[2] . length  <=  80 
->  expresslon[1], bcursor  +  1 

*  len(expresslon[1J. padding)  +  1; 
express lon[2]. padding  -  expresslon[1], padding; 
express ion[1].ecursor  •  expresslon[2].ecursor; 

expresslon[l].str_value  -  express lon[1]. bcursor  +  1  +  express lon[2], length  <-  80 
->  ['$*,  express lon[2].str_va lue] 

*  [*\n\  express  I  on[l],  padding,  '$',  express  lon[2]  .str  valued 

) 

!  expression  RANGE  expression  jprec  RANGE 

!  x  In  [a  ..  b]  Iff  x  In  {a  ..  b)  Iff  a  <-  x  <■  b 
I  [a  ..  b]  is  sorted  In  increasing  order 
{ 

express  I on[1]. length  -  express lon[2], length  +  4  +  express ion[3], length; 
express lon[2]. bcursor  «  express  I on[1], bcursor; 
expression^]. padding  «  expression[l], padding; 
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express ion[3].bcursor  «  express lon[2].ecursor  +  4  +  express lon[3], length  <=  80 
->  express  I on[2].ecursor  +  4 
«  len(expresslon[1]. padding)  +  3; 
express lon[3], padding  •  express  I on[1]. padding; 
express lon[1).ecursor  -  expression^]. ecursor; 

expresslon[1].str_value  «  express lon[2].ecursor  +  4  +  express lon[3]. length  <«  80 
-»  [expresslon[2].str_value,  *  ..  express lon[3].str_value] 

•  [express lon[2].str_value,  "Xn",  expresslon[1]. padding,  ", 
expression^]. str  value]; 

) 

!  expression  NAME  Xprec  DOT 

{ 

express l on[1]. length  -  express lon[2]. length  +  1  +  len(NAME.Xtext); 
expression^]. bcursor  -  express  I on[1].bcursor; 
express lon[2]. padding  •  express lon[l], padding; 

expression^. ecursor  -  express  I on[2].ecursor  +  1  +  len(NAME.Xtext)  <»  80 
->  express lon[2].ecursor  +  1  +  len(NAME.ttext) 

•  len(expresslon[1]. padding)  +  len(NAME.Xtext); 
expresslon[1].str_value  -  express lon[2].ecursor  +  1  +  len(NAME.Xtext)  <-  80 

->  [express ion[2].str_va lue,  *.*,  NAME.Xtext] 

•  [express lon[2] .strva lue ,  "\n*.  expresslon[l], padding,  NAME.Xtext]; 

} 

i  expression  '['  expression  ']'  Xprec  DOT 

{ 

express  lon[1],  length  -  express  I  on[2].  length  +  2  +  expression^] .  length; 
expression^]. bcursor  -  expresslon[l].bcursor; 
express  I on[2] . padding  *  express  I on[1]. padding; 

Express lon[3].bcursor  -  express lon[2].ecursor  +  2  +  express lon[3] . length  <•  80 
->  express lon[2].ecursor  +  1 
t  len(expresslon[1], padding)  +  1; 
expression^], padding  -  express lon[1]. padding; 
express lon[l].ecursor  •  express lon[3].ecursor  +  1; 

express lon[1].str_va lue  -  express lon[2].ecursor  +  2  +  express lon[3]. length  <-  80 
->  [express lon[2].str_va lue,  ”[”,  express lon[3].str_va lue,  “]"] 

•  [expression^]. str_value,  "\n*,  expresslon[1] .padding,  “[", 
express lon[3].str  value,  *]’]; 

} 

I  '('  expression  ')' 

{ 

express l on[1], length  «  2  +  express lon[2]. length; 

express lon[2].bcursor  -  express  I on[l].bcursor  +  2  +  express  I on[2]. length  <•  80 
->  express lon[ 1 ] .bcursor  +  1 

•  len(expresslon[1]. padding)  +  1; 
express lon[21 .padding  ■  express lon[1]. padding; 
expresslon[1].ecursor  «  express lon[2].ecursor  +  1; 

express  I  on[1].str_va  lue  «  express  lon[1]  .bcursor  +  2  +  expression^] .  length  <•  80 
->  ["(",  expression^]. str_value,  ")’] 

•  ["\n*.  express lon[l]. padding,  *(*,  express ion[2].str  value,  ”)“]; 

) 

i  '('  expression  units  ')'  I  tiling  expression 
{ 
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express  I  on[1].  length  «  2  +  expression^].  length  +  units,  length; 
express ion[2].bcursor  •  express lon[1].bcursor  +  2  +  express lon[2]. length 
+  units. length  <-  80 
->  express lon[1].bcursor  +  1 

•  len(expresslon[1]. padding)  +  1; 
expression^].  padding  =  express  I  on[l],  padding; 
units. bcursor  -  express lon[2].ecursor; 
units. padding  -  expr ess l on [1]. padding; 
express  I on[1].ecursor  -  units. ecursor  +  1; 

express  I on[1].str_value  »  express lon[1]. bcursor  +  2  +  express lon[2], length 
+  units. length  <-  80 

->  t“C»  expression^] .str_value,  units. str_value,  ')*] 

•  f\n*.  expresslon[l], padding.  *(',  express lon[2].str  value,  units. str  value, 

•)’]; 

} 

TIME  I  The  current  local  tlie,  used  In  teaporal  events 

{ 

expression. length  •  5; 

express i on. ecursor  -  express  I  on. bcursor  +  5  <-  80 
-»  express  Ion. bcursor  +  5 

•  len(expresslon. padding)  +  5; 

expression. strvalue  «  express  Ion. bcursor  +  5  <«  80 
->  “TIME  “ 

t  [“\n",  express  I  on. padding,  'TIME  “]; 

} 

DELAY  I  The  tine  between  the  triggering  event  and  the  response 

{ 

expression. length  -  6; 

express  I  on. ecursor  -  express  Ion. bcursor  +  6  <-  80 
->  express  I  on. bcursor  +  6 

•  len(expresslon. padding)  +  6; 

expression. strvalue  -  express  I on. bcursor  +  6  <-  80 
->  'DELAY  '  ” 

•  ["\n",  express  ion. padding,  'DELAY  ']; 

) 

PERIOD  I  The  tlee  between  successive  events  of  this  type 

{ 

expression. length  «  7; 

express  Ion. ecursor  -  express  Ion. bcursor  +  7  <-  80 
->  express  Ion. bcursor  +  7 

•  len(express Ion. padding)  +  7; 

expression. str  value  -  express  Ion. bcursor  +  7  <«  80 
->  'PERIOD  '" 

t  t'\n',  express  Ion. padding,  'PERIOD  ']; 

} 

I  Iteral 
{ 

expression. length  -  I Iteral . length; 

I  Iteral .bcursor  •  expression. bcursor; 

I  Iteral  .padding  -  express  I  on. padding; 
express l on. ecursor  ■  I Iteral .ecursor; 


express  Ion.  str  value  -  llteral.str  value; 

} 

!  literal  parametrized  naae  I  literal  with  explicit  type 

{ 

expression. length  -  I iteral . length  +  1  +  paraeetr I zed_nane. length; 

I  Iteral  .bcursor  -  express! on. bcursor; 

I iteral .padding  -  express  Ion. padding; 

paraeetr lzed_naee. bcursor  -  I iteral .ecursor  +  1  +  paraeetr lzed_nane. length  <»  80 
->  I Iteral .ecursor  +  1 
«  I en( I Iteral .padding); 

paraeetr I  zed _naee. padding  -  spaces(paraeetrlzed_naee. bcursor); 
express  I  on. ecursor  •  paraeetrlzed_naee.ecursor; 

expression. str_value  -  I  Iteral  .ecursor  +  1  +  paraeetr  Ized  naee.  length  <•  80 
->  [I Iteral ,str_value,  "e".  paraeetrlzed_naee.str_value] 

•  [llteral.str  value,  ‘\n’,  I  Iteral. padding,  parametrized  name  value]; 

} 

I  '?'  I  An  undefined  value  to  be  specified  later 

{ 

expression. length  -  1 ; 

express  I  on. ecursor  -  express  I  on. bcursor  +  1  <■  80 
->  express  ion. bcursor  +  1 

•  len(expression. padding)  +  1; 

expression. strvalue  ■  express  ion. bcursor  +  1  <«  80 
-»  “?" 

•  ["\n“,  express  I  on. padding,  “?"]; 

} 

i  *r  l  An  undefined  and  Illegal  value 

{ 

expression. length  >  1 ; 

express  I on. ecursor  -  express  I on. bcursor  +  1  <*  80 
->  express  Ion. bcursor  +  1 

•  len(expression. padding)  +  1; 

expression. strvalue  «  express  I  on. bcursor  +  1  <-  80 
->  "  I  ” 

•  [“\n",  expression. padding,  "I"]; 

} 

!  IF  expression  THEN  expression  Biddle  cases  ELSE  expression  Fi 

{ 

express ion[1].  length  -  15  +  expression^] .  length  +  express ion[3].  length 
+  elddle_cases. length  +  express ion[4] . length; 
express  I on[ 2]. bcursor  -  express lon[1], bcursor  +  3; 
expression^]. padding  •  spaces(expre$slon[1]. bcursor); 
express  I on[3] . bcursor  -  express lon[1], bcursor  +  5; 
express lon[3], padding  »  spaces(expression[1]. bcursor); 
elddle  cases. bcursor  »  express lon[1). bcursor-, 
elddle_cases.paddlng  -  spaces(express I on[1]. bcursor); 
expression^]. bcursor  -  expresslon[1], bcursor  +  5; 
express lon[4]. padding  -  spaces(expresslon[1]. bcursor); 
express  I on[1]. ecursor  -  expression^]. ecursor  +  4; 
expresslon[l].str_value  -  express ion[4]. ecursor  +  4  <«  80 
->  ["IF  ",  expression^]. str_value,  "\n",  expression^]. padding,  "THEN  ", 
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expression^]. str  value,  alddle_cases.str_value,  "\n", 
expression^], padding.  "ELSE  *,  expresslon[4].str_value,  ’  FI  "] 

#  [’IF  ",  expresslon[2].str_value,  "\n",  express lon[3], padding,  “THEN  ", 
expresslon[3].str_value,  alddle_eases.str  value,  "\n", 
express lon[4]. padding,  "ELSE  ", "express lon[4].str  value,  "\n", 
express lon[4]. padding,  "  FI  *]; 


■lddle_cases 

:  Riddle  cases  ELSE  IF  expression  THEN  expression 
{ 

R Idd I e_cases[1]. length  -  13  ♦  elddle_cases[2]. length  +  express lon[1], length 
♦  express lon[2]. length; 

ilddle_cases[2].bcursor  -  *lddle_cases[l].bcursor; 

■iddle_cases[2]. padding  -  ■ lddle_cases[l], padding; 
express l on[l].bcursor  ■  elddle_cases[1].bcursor  +  8; 
express  I  on [ 1 ] . padding  -  • Idd le~cases[1 ] .padding; 
express lon[2].bcursor  «  Rlddle~cases[1].bcursor  +  5; 
express l on[2]. padding  -  Rlddle~cases[1], padding; 

■lddle_cases[1].str_value  «  [eTddle_cases[2].str  value,  "\n", 
■lddTe_cases[l], padding,  *ELSE_IF  ",  express ion[1].str_value,  "\n“, 

Riddle  cases[1], padding,  "THEN-",  express lon[2].str  value]; 

} 

I 

I 

{ 

a  Idd  I e  cases.  length  -  0; 

■Iddle  cases. str  value  -  '"; 

} 


quantifier 
:  ALL 

{ 

quantifier. length  -  3; 

quantif ier.ecursor  -  quantlf ler.bcursor  <-  80 
->  quantlf ler.bcursor  +  3 

*  len(quant If ler. padding)  +  3; 

quantlf ler.str  value  «  quantlf ler.bcursor  <-  80 
->  "ALL" 

*  ["\n",  quantlf ler.padd l ng.  "ALL"]; 

} 

I  SOME 
{ 

quantlf ler. length  ■  4; 

quantlf Ier.ecursor  -  quantlf ler.bcursor  <«  80 
->  quantlf ler.bcursor  +  4 

*  len(quantlf ler. padding)  +  4; 

quantlf ler.str  value  -  quantlf ler.bcursor  <-  80 
->  "SOME" 

*  C"\n",  quantlf ler. padding,  "SOME"]; 
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} 

NUMBER 

{ 

quantifier. length  •  6; 

quant  If ler.ecursor  -  quantifier .bcursor  <•  80 
->  quantifier. bcursor  +  6 

•  len(quant If ler. padding)  +  6; 

quant  If ler.str  value  -  quantifier. bcursor  <«  80 
->  "NUMBER"  " 

•  f\n",  quant  If  ler.  padding,  "NUMBER"]; 

} 

SUM 

{ 

quantifier. length  -  3; 

quant  If ler.ecursor  -  quant  If ler. bcursor  <«  80 
->  quant  If ler. bcursor  +  3 

•  len(quant If ler. padding)  ♦  3; 

quant  If ler.str  value  «  quant  if ler. bcursor  <-  80 
->  "SUM” 

•  ["\n",  quant  if ler. padding,  "SUM"]; 

} 

PRODUCT 

{ 

quant  If ler. length  -  7; 

quant  If ler.ecursor  -  quant  If ler. bcursor  <•  80 
->  quantifier. bcursor  +  7 

•  len(quantlf ler. padding)  +  7; 

quant  if ler.str  value  «  quantifier. bcursor  <-  80 
->  "PRODUCT "' 

•  [“\n",  quant  If ler.  padding,  "PRODUCT"]; 

} 

SET 

{ 

quantifier. length  -  3; 

quant  if ler.ecursor  -  quantifier. bcursor  <■  80 
->  quant  if ler. bcursor  +  3 

•  len(quantlf ler. padding)  +  3; 

quant  if ier.str  value  »  quantifier. bcursor  <»  80 
->  "SET" 

•  ["\n",  quant  if ier. padding,  "SET"]; 

) 

MAXIMUM 

{ 

quantifier. length  -  7; 

quant  If  ler.ecursor  «  quant  If ier. bcursor  <■  80 
->  quant  If ier. bcursor  +  7 

•  len(quantlf ler. padding)  +  7; 

quant  If ler.str  value  »  quant  If ler .bcursor  <=  80 
->  "MAXIMUM"' 

•  ["\n",  quant  If ler. padding,  "MAXIMUM"]; 

} 
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MINIMUM 

{ 

quantifier. length  -  7; 

quantlf ler.ecursor  -  quant  If ler.bcursor  <•  80 
->  quantlf ler.bcursor  ♦  7 

•  len(quantlf ler. padding)  +  7; 

quantlf ier.str  value  •  quantlf ler.bcursor  <-  80 
->  “MINIMUM"' 

•  ["\n",  quantlf ler. padding,  “MINIMUM"]; 

} 

UNION 

{ 

quantlf ler. length  -  5; 

quantlf ler.ecursor  -  quantlf ler.bcursor  <•  80 
->  quantlf ler.bcursor  +  5 

•  len(quant If ler. padding)  +  5; 

quantlf ier.str  value  -  quantlf ler.bcursor  <-  80 
->  "UNION" 

•  ["\n",  quantlf ler. padding,  "UNION"]; 

} 

INTERSECTION 

{ 

quantlf ler. length  -  12; 
quantlf ler.ecursor  -  quantlf ler.bcursor  <•  80 
->  quantlf ler.bcursor  ♦  12 

•  len(quantifier. padding)  +  12; 

quantlf Ier.str  value  -  quantlf ler.bcursor  <•  80 
->  "INTERSECTION" 

•  t"\n“,  quant  If ler. padding,  "INTERSECTION"]; 

} 


restriction 

:  SUCH  expression 

{ 

restriction. length  -  10  +  expression. length; 
express  1  on. bcursor  -  restrict  Ion. bcursor  +  10  <*  80 
->  restriction. bcursor  +  10 

*  ien(restrlctlon. padding)  +  10; 
expression. padding  -  spaces(expresslon. bcursor); 
restrict  I  on. ecursor  -  expression. ecursor; 
restrlctlon.str_value  -  restrict  Ion. bcursor  +  10  <«  80 

->  ["SUCH  THAT  ",  expression. str_value] 

#  ["\n",  restriction. padding,  "SUCH  THAT  ",  express  Ion. str  value] 

) 


restriction. length  •  0; 

restrict  I  on. ecursor  ■  restriction. bcursor; 

restriction. str  value  « 
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1 1  ter a  I 

:  INTEGER  LITERAL 

{ 

literal. length  -  len( I NTEGER_L I TERAL . Xtext ) 

literal. str  value  -  I  It era  I .bcursor  +  len( I NTEGER  LITERAL. Xtext)  <«  80 
->  INTEGER  LI TERAL. Xtext 

•  [*\n\  literal,  padding,  I  NTEGER  _L  I  TERAL .  Xtext  ] ; 

I Iteral .ecursor  -  I Iteral .bcursor  +  7en( INTEGER  LI TERAL. Xtext)  <«  80 
->  I Iteral. bcursor  +  len( I NTEGERJ.  ITERAL .Xtext) 

•  len(  I  Iteral  .padding)  +  len(  INTEGER  LI  TERAL.  Xtext); 

> 

|  REAL  LITERAL 

{ 

I Iteral. length  «  len(REAL  LITERAL. Xtext); 

I  Iteral. str  value  -  I Iteral .bcursor  ♦  len(REAL  LI TERAL. Xtext)  <-  8C 

->  real  lTteral. Xtext 

•  [“\n",  I Iteral .padding,  REAL_LITERAL. Xtext]; 

I Iteral  .ecursor  -  I  Iteral  .bcursor  ♦  I en(REAL  LITERAL. Xtext)  <«  80 
->  I Iteral .bcursor  +  len(REAL_L ITERAL. Xtext) 

»  lent  I iteral .padding)  +  len(REAL  LITERAL. Xtext); 

} 

|  CHAR  LITERAL 

{ 

I iteral. length  -  I enfCHARL ITERAL. Xtext); 

I Iteral. str  value  -  I Iteral .bcursor  +  lent CHAR  LITERAL. Xtext)  <«  80 
->  CHARlTtERAL. Xtext 

•  f\n" ,  I  Iteral. padding,  CHARL I  TERAL.  Xtext]; 

I Iteral .ecursor  -  I Iteral ,bcursor~+  Jen(CHAR_L ITERAL. Xtext)  <-  80 
->  I iteral .bcursor  +  len(CHAR  LITERAL. Xtext) 

•  lent  I Iteral. padding)  +  lentCHAR  LI TERAL. Xtext); 

} 

!  STRING  LITERAL 

{ 

I  Iteral.  length  -  lentSTRING_UTERAL. Xtext); 

I Iteral. str  value  «  I iteral .bcursor  +  I en(STR I NG  LITERAL. Xtext)  <=  80 
->  STR I NG~L I TERAL. Xtext 

«  ["VT, 'literal. padding,  STR I NG_L I TERAL . Xtext]; 

I Iteral .ecursor  -  I  Iteral  .bcursor  +  len(STRING  LITERAL. Xtext)  <«  80 
->  I Iteral. bcursor  +  lentSTRING  LI TERAL. Xtext) 

•  lent  I  Iteral. padding)  +  lentSTRING  LITERAL. Xtext); 

) 

i  '•*  NAME  I  enumeration  type  literal 

{ 

I iteral . length  -  1  ♦  len(NAME. Xtext); 

I Iteral .ecursor  -  I  Iteral  .bcursor  +  1  +  len(NAME. Xtext)  <-  80 
->  I Iteral .bcursor  +  1  +  lent NAME. Xtext) 

•  lent l Iteral .padding)  *  1  ♦  len(NAME. Xtext); 

I Iteral. str  value  ■  l Iteral .bcursor  +  1  + lent  NAME. Xtext)  <*  80 
->  [’#",  NAME. Xtext] 
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»  [-\n-,  literal. padding,  “#\  NAME .Xt ext]; 


} 

!  *[*  expressions  ']'  I  sequence  literal 

£ 

I Iteral . length  ■  2  +  expressions. length; 
express  Ions. bcursor  -  I Iteral .bcursor  +  1  <80 
->  I Iteral .bcursor  +  1 

•  len(l Iteral. padding)  +  1; 

express  Ions. padding  -  spaces  ( I  Iteral  .bcursor  4-1); 

I Iteral .ecursor  -  express  I ons.ecursor  *  1; 

I Iteral .st revalue  -  I Iteral .bcursor  t  1  <80 
->  [*[*,  express  Ions. st r_va I ue.  *]“) 

•  ["\n",  I Iteral .padding,  ’[*,  express  I ons.str  value,  "]”]; 

) 

!  '{'  expressions  '}'  I  set  literal 

£ 

l Iteral . length  -  2  ♦  expressions. length; 
express  Ions. bcursor  -  I  iteral  .bcursor  +  1  <80 
->  l Iteral .bcursor  +  1 

•  ien( i iteral. padding)  +  1; 

express  Ions. padding  -  spaces ( I iteral .bcursor  +  1); 
l iteral .ecursor  ■  express  ions. ecursor  ♦  1; 

I Iteral .strvalue  -  I Iteral .bcursor  +1  <80 
->  ["£“,  express  I ons.str  value,  *)*] 

•  ["\n“,  I Iteral .padding,  •{*,  express  I ons.str  value,  ’}*]; 

} 

!  '£'  expression  coeeent  expressions  I  aap  literal 

£ 

1 Iteral . length  -  3  +  expression. length  +  coetent . length  +  expressions,  length; 
coeeent. bcursor  -  express  Ion.  ecursor  1; 

express  Ion. bcursor  -  I  Iteral  .bcursor  +  1  <80 
->  I iteral .bcursor  +  1 
t  len( I Iteral .padding)  ♦  1; 
expression. padding  -  spaces(expresslon. bcursor); 
express  Ions. bcursor  -  coeeent. length  >  O 
->  len(express I  on. padding) 

•  express  I  on. ecursor  +  2  <80 
->  express  Ion. ecursor  +  1 

•  len(expresslon. padding); 

express  ions. padding  -  express  I  on. padding; 
l Iteral .ecursor  -  express  Ions. ecursor  +  1; 

l Iteral .str_value  -  (coeeent. length  »  0)  &&  ( I Iteral .bcursor  +1  <  80) 

->  ["£“,  expression. str_value,  coseent.str  value,  expression. padding, 

express  Ions,  st r_va I ue,  ')’] 

•  (coeeent. length  >  0)  &&  ( l iteral .bcursor  +  1  >«  80) 

->  ["\n",  I  Iteral  .padding,  ’(’,  expression. str_value,  comment. str_vaiue, 
express  I  on. padding,  expressions. str_value,  "}’] 

•  (coeeent. length  -«  0)  &&  ( I Iteral .bcursor  +1  <  80) 

&&  (expression. ecursor  +  3  <-  80) 

->  ['£".  express  Ion. str  value,  ";  ",  coeeent. str  value,  express  ions. str  value, 
’)"] 
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•  (consent. length  -«  0)  &&  ( I Iteral .bcursor  +  1  >»  80) 
iS  (express  I  on. ecursor  +  3  <«  80) 

->  [“\n",  I Iteral .padding,  *{*,  express  Ion. str  value,  “,  comment. str  value, 
express  Ions. st r_va I ue,  “)"] 

•  (consent. length  --  0)  &&  (I Iteral. bcursor  +  1  <  80) 

&&  (express ion. ecursor  +  3  <-  80) 

->  [*{”,  expression. str_value,  *;  *.  ‘\n“,  expression. padding, 
cossent.str_value,  expressions. str_value,  "}“] 

«  [*\n",  I iteral .padding,  *{*,  express  I  on. str_va lue,  ",  “\n", 
expression. padding,  consent. str  value,  express  Ions,  str  value, 

) 

!  '['  pair  list  ']*  I  tuple  literal 

{ 

I  Iteral. length  -  2  +  pa IrJ  1st . length; 
pa  I r_ 1 1 st. bcursor  «  I Iteral .bcursor  +  1  <80 
->  l Iteral .bcursor  +  1 

•  lend  Iteral. padding)  +  1; 

pa  I rj 1st. padding  -  spaces( literal .bcursor  +  1); 

I  Iteral  .ecursor  -  palrj  1st.  ecursor  +  1; 

I Iteral .strva lue  «  I Iteral .bcursor  +1  <80 
->  ("[“.  palrj  Ist.str  value,  "]*] 

*  t"\n",  I Iteral .padding,  “[",  pair  1 1st. str  value, 

} 

!  T  pair  I  one  of  literal 

( 

I Iteral . length  -  2  +  pair. length; 
pair. bcursor  -  I Iteral .bcursor  +  1  <  80 
->  I Iteral .bcursor  +  1 

*  lend  iteral  .padding)  +  1; 

pair. padding  ■  spacesd  iteral  .bcursor  +  1); 

I  Iteral  .ecursor  >  pair. ecursor  +  1; 

I  Iteral  .str_va lue  -  I  Iteral  .bcursor  +  1  <80 
->  ["(“.  palr.strvalue,  ")"] 

#  t"\n",  I  Iteral  .padding,  pair. str  value, 

} 


I  relation  literals  are  sets  of  tuples 
expressions 

:  expression  list  9 

{ 

expressions. length  -  express  I on_ 1 1st. length; 
expression  1 1st.  bcursor  ■  express  Ions,  bcursor-, 
expression  1 1st.  padding  -  express  Ions. padding; 
express  Ions. ecursor  -  expressionj 1st.  ecursor; 

expressions. str_value  -  expression  1 1st. str  value;  9 

I 

I 

{ 

expressions. length  -  0; 

express  Ions. ecursor  «  express  ions. bcursor; 
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} 


express  Ions,  str  value  - 

} 


palrj  1st 

:  pair  list  pair 
( 

palrj  I st [  1  ] .  length  «  palrj  lst[2].  length  +  2  +  pair. length; 
palrj  lst[2]. bcursor  -  palrj  lst[1].bcursor; 
palrj ist[1]. ecursor  •  palr.ecursor; 
pa  I  r_l  lst[2]. padding  •  palrj  lst[1].  padding; 
palr.bcursor  -  palrj  lst[2].ecursor  +  2  <■  80 
->  palrj  ist[2]. ecursor  +  2 

•  ien(palr_l lst[1]. padding); 

palrj  lst[1].str_value  -  palrj  lst[2].ecursor  +  2  <«  80 
->  [palrj lst[2].str_value,  *,  ",  pair.str_value] 

•  [palrj I st [2] .strvalue,  ",  ",  “\n",  pal r_ 1 1st [ 1 ] . padding,  pair. str  value] 
pair. padding  -  pair  I i st [ 1 ] . padding; 

) 

!  NAME  pair 

{ 

pair  1 1st. length  »  len(NAME.Xtext)  +  pair. length; 
palr.bcursor  «  pair  1 1st. bcursor  +  len(NAME.Xtext)  <*  80 
->  pair  1 1st. bcursor  +  len(NAME.Xtext) 

•  len(palr  l 1st. padding)  +  len(NAME.Xtext); 
pair. padding  -  palrj  1st. padding; 

palrj  1st .ecursor  -  palr.ecursor; 

pair  I Ist.str  value  »  pair  1 1st. bcursor  +  len(NAME.Xtext)  <-  80 
->  [NAME.Xtext,  palr.strvalue] 

•  [“\n",  pair  1 1st. padding,  NAME.Xtext,  palr.str  value]; 

} 

!  pair 

{ 

palrj  1st.  length  ■  pair,  length; 
palr.bcursor  «  palrj  Ist.hcursor; 
pair. padding  -  palrj  1st. padding; 
palrj  1st. ecursor  -  palr.ecursot ; 
pair  1 1st. str  value  «  pair. str  value; 


pair 

:  NAME  BIND  expression 

{ 

pair. length  «  len(NAME.Xtext)  ♦  4  +  expression,  length; 
express  Ion. bcursor  «  palr.bcursor  +  len(NAME.Xtext)  +  4  <•  80 
->  palr.bcursor  +  len(NAME.Xtext)  +  4 
t  len(palr. padding)  ♦  len(NAME.Xtext)  +  4; 
palr.ecursor  >  express  Ion. ecursor; 
express  I  on. padding  «  pair. padding; 

pair. str  value  *  palr.bcursor  +  len(NAME.Xtext)  +  4  <»  80 
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->  [NAME.Xtext,  ”  expression. str_va!ue] 

#  ["\n“,  pair. padding,  NAME.Xtext,  “  ",  expression. str  value]; 


units 

;  NANOSEC 
{ 

units,  length  -  8; 

units. ecursor  -  units. bcursor  +  8  <  80 
->  units. bcursor  +  8 
•  len(un Its. padding)  +  8; 
units. str  value  -  units. bcursor  +  8  <  80 
->  "NANOSEC" 


#  ["\n",  units. padding,  “NANOSEC"]; 

) 

!  MICROSEC 

{ 

units. length  »  8; 

units. ecursor  -  units. bcursor  +  8  <  80 
->  units. bcursor  +  8 

#  len(unlts. padding)  +  8; 
units.str_value  «  units. bcursor  +  8  <  80 

->  "MICROSEC" 

*  [“\n“,  units. padding,  "MICROSEC"]; 

} 

I  MILLISEC 
{ 

units. length  «  8; 

units. ecursor  -  units. bcursor  +  8  <  80 
->  units. bcursor  +  8 

#  len(unlts. padding)  +  8; 

units. str  value  -  units. bcursor  +  8  <  80 
->  "MILLISEC" 

t  ["\n",  units. padding,  "MILLISEC"]; 

} 

!  SECONDS 
{ 

units. length  «  7; 

units. ecursor  -  units. bcursor  +  7  <  80 
->  units. bcursor  +  7 

*  len(unlts. padding)  +  7; 

units. str  value  -  units. bcursor  +  7  <  80 
-»  "SECONDS" 

*  [*\n\  units. padding,  "SECONDS"]; 

} 

!  MINUTES 
{ 

units. length  «  7; 

units. ecursor  >  units. bcursor  +  7  <  80 
->  units. bcursor  +  7 
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«  !en(unlts. padding)  +  7; 
units. str  value  -  units. bcursor  +  7  <  80 
->  "MINUTES" 

#  ["\n“,  units. padding,  "MINUTES"]; 

) 

!  HOURS 
{ 

units. length  -  5; 

units. ecursor  »  units. bcursor  +  5  <  80 
->  units. bcursor  +  5 

#  len(unlts. padding)  +  5; 

units. str  value  »  units  .bcursor  +  5  <  80 
->  “HOURS" 

#  [’\n“,  units. padding,  “HOURS"]; 

) 

!  OAYS 

{ 

units. length  -  4; 

units. ecursor  -  units. bcursor  +  4  <  80 
->  units. bcursor  +  4 

#  len(unlts. padding)  +  4; 

units. str  value  -  units. bcursor  +  4  <  80 
->  “DAYS" 

#  [“\n",  units. padding,  “DAYS"]; 

} 

!  KEEKS 
{ 

units, length  »  5; 

units. ecursor  -  un Its .bcursor  +  5  <  80 
->  units. bcursor  +  5 

#  len(unlts. padding)  +  5; 

units. strvalue  -  units. bcursor  +  5  <  80 
->  "KEEKS" 

#  [“\n",  units. padding,  "KEEKS"]; 


operator  1 1st 

:  operator  list  operator  syebol 

{ 

operatorl lst[1]. length  •  operatorj lst[2] . length  +  operator  symbo I .  length ; 
operatorl lst[2]. bcursor  -  operator  I  lst[  1  ] .bcursor ; 
operatorj  I  st  [  2]  .padding  ■  operator  I  lst[  1]  .padding; 
operator  l 1st [ 1 ] . ecursor  •  operator  syabo I  .ecursor ; 
operator_syibo I  .padding  -  operator  jist[l]. padding; 
operator_sy*bo I .bcursor  «  operator  I  i st [ 2] . ©cursor ; 
operator  l  lst[l].str  value  •  [operator  I  lst[2] .str  va lue, 
operator  synbol  .str  value  ]; 

) 

I  operator_sy«bol 

( 
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operator  1 1st.  length  -  operator_syabol . length; 
operator” 1 1st. ecursor  «  operator_syabo I .ecursor ; 
operator”syabol .bcursor  «  operatorj Ist.bcursor; 
operator  syabo I .padding  «  operator_l 1st. padding; 
operator-! Ist.str  value  «  operator_syabol ,str_value; 

} 


operator  syibol 
:  MOT 

{ 

operatorsyabo I . length  -  2; 

operator  syabo l.str  value  -  operator_syapol  .bcursor  +  2  <-  80 

«  —  M 

-> 

•  [*\n\  operator_syabol. padding. 

operator  syabo I .ecursor  «  operator_syabo I .bcursor  +  2  <«  80 
->  operator  syabo I  .bcursor  +  2 

•  len(operator_sy«bo I .padding)  +  2; 

} 

!  AMO 

{ 

operatorsyabo I . length  -  2; 

operatorsyabol .strvalue  «  operator_syabo I .bcursor  +  2  «  80 

•  ["\n",  operatorsyabol .padding.  “&  “]; 

operator_symbo I .ecursor  «  operator_syabo I .bcursor  +  2  80 

->  operatorsyabo I .bcursor  +  2 

•  len(operator  syabo  I  .padding)  +  2; 

) 

!  Oft 

{ 

operator_symbo I . length  «  2; 

operator_syabo I  .str  value  ■  operator_syabo I  .bcursor  2  <■  80 
->  "i  * 

•  ["\n",  operator_syabo I .padding,  "!  "]; 

operator  syabo l  .ecursor  -  operator_syabol .bcursor  +  2  <«  80 
->  operator  symbol .bcursor  +  2 

•  len(operator  symbol  .padding)  +  2; 

) 

!  IMPLIES 

{ 

operator_syabo I . length  «  3; 

operatorsyabol .strvalue  -  operator_syabo I .bcursor  +  3  <-  80 
->  ’*>  " 

•  [”\n\  operator_syabol .padding,  "»> 

operator  syabo I .ecursor  ■  operator_sy«bo I .bcursor  +  3  <»  80 
->  operator_syabo I .bcursor  +  3 
«  len(operator  syabo I .padding)  +  3; 

) 

!  IFF 

{ 
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operator_syabo I .  length  -  4; 

operator_syabol .str_value  -  operator_syabol .bcursor  +  4  <«  80 
->  "<*> 

•  [“\n“,  operator_$yabol .padding,  “<->  “]; 
operator_syabo I .ecursor  «  operator  syabol .bcursor  +  4  <»  80 

->  opsrator_syabo I .bcursor  +  4 

•  len(operator  syabo I .padding)  +  4; 

) 

!  '<' 

{ 

operatorsyabo I . length  -  2; 

operator  syabol.str  value  •  operator  syabo I .bcursor  +  2  <-  80 
->  “<  " 

•  ["\n“,  operator_syabo  I  .padding,  “<  ']; 
operator_syabo I .ecursor  -  operatorsyabo I .bcursor  +  2  <-  80 

->  operator_syabo I .bcursor  +  2 

•  len(operator  syabo I .padding)  +  2; 

) 

!  *>' 

{ 

operator  syabo l . length  «  2; 

operatorsyabol .strvalue  -  operator_syabo I .bcursor  +  2  <«  80 
->  ">  * 

•  ["\n\  operator_syabo I  .padding,  "> 
operatorsyabo I .ecursor  -  operatorsyabo I .bcursor  +  2  <•  80 

-»  operator_syabo I .bcursor  +  2 
«  len(operator  syabol .padding)  +  2; 

) 

!  '■* 

{ 

operatorsyabol . length  -  2; 

operator  syabol .str  value  -  operator  syabol  .bcursor  +  2  <«  80 

->  "at 

«  ["\n",  operatorsyabol .padding,  "•  "]; 
operator_syabo 1 .ecursor  •  operator_syabo I .bcursor  +  2  <-  80 
->  operator_syabo I  .bcursor  +  2 

•  len(operator  syabol  .padding)  +  2; 

} 

!  LE 
C 

operator  syabo I . length  -  3; 

operatorsyabol .strvalue  -  operator  syabol .bcursor  +  3  <-  80 
->  "<■ 

•  ["\n",  operator_syabol .padding,  ”<-  "]; 
operator_syabo l .ecursor  -  operator_syabo I .bcursor  +  3  <«  80 

->  operator_syabo I .bcursor  +  3 

•  len(operator  syabol .padding)  +  3; 

) 

!  GE 
{ 

operator_syabo I . length  «  3; 
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i 


operator_syabol .str_value  -  operator_syBbol .bcursor  +  3  <=  80 
->  ">«  " 

•  [*\n‘,  operator_sy»bo l .padding,  ”>-  *]; 
operator_syabol .ecursor  -  operator_syibo I .bcursor  +  3  <*  60 

->  operator_syfflbo I .bcursor  +  3 

•  len(operator  symbol .padding)  +  3; 

} 

!  NE 

{ 

operator_sy«bo I . length  »  3; 

operator_symbol .str_value  -  operator_symbo I .bcursor  +  3  <»  80 

«  —  N 
->  ■ 

•  ["\n“,  operator_sy«bo I  .padding,  “]; 
operatorsymbol .8cursor  -  operator_sy«bo I .bcursor  +  3  <«  80 

->  op8rator_symbo I .bcursor  +  3 
«  len(operator  symbol .padding)  +  3; 

} 

!  NLT 
{ 

operatorsymbo I . length  -  3; 

operatorsymbol .strvalue  »  operator_symbo I .bcursor  +  3  <-  80 
->  *~< 

«  ["\n“,  operator_symbo I  .padding,  “<  "]; 
operator  symbol .ecursor  -  operator _symbo I .bcursor  +  3  <-  80 
->  operator  symbo I .bcursor  +  3 

•  len(operator_symbo I  .padding)  +  3; 

) 

!  NGT 

{ 

operatorsymbo I . length  .  3; 

operatorsymbol .strvalue  »  operator_symbo I .bcursor  +  3  <■  80 

M 

->  > 

•  ["\n",  operator_symbo I .padding,  ’"*  "]; 
operator_symbo l .ecursor  =  operator_symbo I .bcursor  +  3  <-  80 

->  operator_symbol .bcursor  +  3 

•  len(operator  symbol .padding)  +  3; 

} 

!  NLE 

{ 

operatorsymbo I . length  -  4; 

operator_symbol .strvalue  -  operator_symbo I .bcursor  +  4  <«  80 
->  " ”<* 

•  [“\n",  operator_symbol .padding,  — «•  "]; 
operator_symbo I .ecursor  »  operator  symbol  .bcursor  +  4  <■  80 

->  operatorsymbo  I  .bcursor  +  4 

•  len(operator  symbol .padding)  +  4; 

) 

!  NGE 
{ 

operator_symbo I . length  -  4; 

operator_symbol .str  value  »  operator  symbol  .bcursor  +  4  <«  80 


i 


i 


i 


i 


I 
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-> 

•  [”\n“,  operator_symbol .padding,  "]; 
operator_symbo I .ecursor  -  operator_symbo I .bcursor  +  4  <»  80 

->  operator_symbo I  .bcursor  +  4 

•  I en (operator  syebo I .padding)  +  4; 

} 

EQV 

{ 

op8rator_symbo I . length  -  3; 

operator_symbol .str_value  -  operator_symbo I .bcursor  +  3  <•  80 
->  "**  “ 

•  [“\n\  operatorsymbol .padding,  *]; 
operator_syabol .ecursor  -  operator_syabo I .bcursor  +  3  <«  80 

->  operatorsymbo I .bcursor  +  3 

•  len(operator  symbol .padding)  +  3; 

) 

NEQV 

( 

operatorsymbo I . length  -  4; 

operatorsymbol .str  value  •  operator  symbol .bcursor  +  4  <»  80 

->  " ~*m  " 

«  ["\n“,  operator_symbo I .padding,  "]; 

operatorsymbo I .ecursor  -  operator_sy«bo I .bcursor  +  4  <•  80 
->  operatorsymbo I .bcursor  +  4 

•  len(operator  symbol .padding)  +  4; 

) 

V 

{ 

operator  symbo I . length  -  2; 

operatorsymbol  .str  value  «  operator_symbo I .bcursor  +  2  <«  80 
->  "+  " 

•  [“\n",  operator_symbo I .padding,  "+  "]; 
operatorsymbo I .ecursor  ■  operatorsymbo I .bcursor  +  2  <»  80 

->  operatorsymbo l .bcursor  +  2 

•  len(operator_symbo I .padding)  +  2; 


{ 

operatorsymbo I . length  ■  2; 

operator  symbol. str  value  »  operator  symbol  .bcursor  +  2  <-  80 
->  ■_  * 

•  [“\n",  operator_symbo I .padding, 
operator_symbo 1 .ecursor  -  operator_symbol .bcursor  +  2  <-  80 
->  operator_symbo I .bcursor  +  2 
t  len(operator_symbo I  .padding)  +  2; 


{ 

operator  symbo  I .  length  -  2; 

operatorsymbol .str  value  -  operator  symbol  .bcursor  +  2  <-  80 
-»  *•  • 
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•  [ “ \n " .  operatorsyabo I .padding,  *•  *]; 

operator  syabol .ecursor  »  operator _sy*bo I .bcursor  +  2  <»  80 
->  operator_syabol .bcursor  +  2 

•  len(operator  syabol .padding)  +  2; 

} 

{ 

operator_syabo I . length  «  2; 

operatorsyabol .str_value  -  operator_syabo I .bcursor  +  2  <-  80 
->  V  “ 

•  [“\n“,  operator_syabol .padding.  V  "]; 

operator  syabo I .ecursor  ■  operator_syabo I .bcursor  +  2  <»  80 
->  operatorsyabo I .bcursor  +  2 

•  len(operator  syabo I .padding)  +  2; 

} 

MOD 

{ 

operator  syabo I . length  -  4; 

operator  syabol .str_value  «  operator_syabo I .bcursor  +  4  <«  80 
->  “MOD  “ 

«  [”\n“,  operator  syabo  I  .padding,  'MOD  “); 
operator  syabol .ecursor  «  operator_syabol .bcursor  +  4  <«  80 
->  operator  syabol .bcursor  +  4 

•  len(operator  syabol .padding)  +  4; 

} 

EXP 

{ 

operatorsyabo I . length  «  3; 

operator  syabol .strva I ue  ■  operator_syabo I .bcursor  +  3  <»  80 
_> 

•  [H\n“,  operatorsyabo I .padding,  “•*  "]; 

operator  syabol .ecursor  -  operator_syabo I .bcursor  +  3  <»  80 
->  operator_syabo I .bcursor  +  3 
«  len(operator_syabo I .padding)  +  3; 

} 

U 

{ 

operator  syabol . length  -  2; 

operator  syabol .str_value  -  operator_syabo I .bcursor  +  2  <=  80 
->  "U  ■ 

•  [“\n",  operator_syabol .padding,  “U  ’]; 

operator  syabol .ecursor  ■  operator_syabo I .bcursor  +  2  <«  80 
->  operator_syabo I .bcursor  +  2 

•  len(operator  syabol .padding)  +  2; 

} 

APPEND 

{ 

operator  syabol . length  »  3; 

operator  syabol .str_value  »  operator_syabo I .bcursor  +  3  <-  80 

"  I  I  “ 

*>  I  » 

•  ["\n“,  operator_syabol .padding,  "!!  ']; 


operator_syebol .ecursor  »  operator_syebo I .bcursor  +  3 
->  operator_syebo I .bcursor  +  3 

•  len(operator  synbo I  .padding)  +  3; 

} 

!  IN 

{ 

operator_syabo I . length  -  3; 

operator  syabol.str  value  -  operator  syebo  I  .bcursor  + 
->  ‘IN”" 

•  [“\n“,  operator_syebo I .padding,  "IN  “]; 
operator_sy«bo I .ecursor  -  operator_sy»bo I .bcursor  +  3 

->  operator_syebo I .bcursor  +  3 

•  len(operator  syebo I .padding)  +  3; 

} 

!  RANGE 

{ 

operator  syebo I . length  -  3; 

operatorsyabol .str_value  -  operator_sy»bo I .bcursor  + 
-> 

•  ["\n",  operator_syebo I .padding,  “..  "]; 
operatorsyebo I .ecursor  -  operator_syebo I .bcursor  +  3 

->  operatorsyebo I .bcursor  +  3 

•  len(operator_syebol .padding)  +  3; 

} 

»  *  * 

I 

{ 

operatorsyebo I . length  «  2; 

operator  symbol  .st r  value  «  operator  symbol .bcursor  + 

•  [“\n“,  operator_syebol .padding,  “]; 
operatorsyebo I .ecursor  •  operator_syebo I .bcursor  +  2 

->  operator_symbo I .bcursor  +  2 

•  len(operator_symbol .padding)  +  2; 

} 

!  T 
{ 

operator_symbo I . length  «  2; 

operator  syabol.str  value  »  operator_symbo I .bcursor  + 

t  [”\n",  operator_syebo I .padding,  ’[ 
operator_syebo I .ecursor  ■  operator  syebo I .bcursor  +  2 
->  operator_syebo l .bcursor  +  2 

•  len(operator_syabo l .padding)  +  2; 


coeeent 

:  COMMENT  coeeent 

{ 

coeeent [ 1]. st r_va I ue  -  coeaent[l]. bcursor  »«  0 
->  [COMMENT. itext, comeent[2J ,str  value] 


<-  80 

3  <-  80 

<-  80 

3  <-  80 

<■  80 

2  <-  80 

<-  80 

2  <»  80 

<«  80 


174 


•  coMent[1].bcursor  +  2  +  len(COMMENT.Xtext)  <•  80 
->  ["  COMMENT. Xtext,  coaaent[2) .str_va lue] 

•  [ " \n " , COMMENT . Xtext ,  coaaent[2].str_value]; 
coa»ent[2].bcursor  «  0; 

coaaent[1]. length  ■  len(COMMENT.Xtext)  +  coaaent[2] . length; 

} 

!  Xprec  SEMI 

{ 

coaaent.st revalue  - 
coaaent. length  -  0; 
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APPENDIX  C 


SAMPLE  INPUT  1 


FUNCTION  square  root  {precision:  real}  WHERE  precision  >0.0 
MESSAGE (X:  real) 

WHEN  X  >-  0.0 
REPLY(y:  real) 

WHERE  y  >-  0.0  &  approx  I aates(y  *  y,  x) 

OTHERWISE  REPLY  EXCEPTION  laag Inary  square_root 
CONCEPT  approxl«ates(r1  r2:  real) 

—  True  If  rl  Is  a  sufficiently  accurate  approxlaat Ion  of  r2. 

—  The  precision  Is  relative  rather  than  absolute. 

VALUE (b :  boolean) 

WHERE  b  <«>  abs((r1  -  r2)  /  r2)  <«  precision 
END 
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SAMPLE  OUTPUT  1 


FUNCTION  square_root{preclslon  :  real} 

WHERE  precision  >  0.0 

MESSAGE  (x  :  real) 

WHEN  x  >-  0.0 
REPLY  (y  :  real) 

WHERE  y  >»  0.0  &  approx  I «ates(y  *  y,  x) 

OTHERWISE 

REPLY  EXCEPTION  liag lnary_square_root 

CONCEPT  approxl«ates(r1  r2  :  real) 

—  True  If  rl  Is  a  sufficiently  accurate  approximation  of  r2. 

—  The  precision  Is  relative  rather  than  absolute. 


VALUE  (b  -.  boolean) 

WHERE  b  <»>  abs((r1  -  r2)  /  r2)  <=  precision 


END 
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SAMPLE  INPUT  2 


TYPE  rational  INHERIT  equal  I ty{ rational} 

MODEL(nua  den:  Integer) 

INVARIANT  ALl(r:  rational  ::  r.den  '•  0) 

MESSAGE  ratlo(nua  den:  integer) 

WHEN  den  0  REPLY(r:  rational) 

WHERE  r.nua  ■  nua,  r.den  >  den 
OTHERWISE  REPLY  EXCEPTION  zero  denoalnator 
MESSAGE  add(x  y:  rational)  OPERATOR  + 

REPLY(r:  rational) 

WHERE  r.nua  -  x.nua  *  y.den  +  y.nua  •  x.den,  r.den  -  x.den  *  y.den 

MESSAGE  aultlply(x  y:  rational)  OPERATOR  • 

REPLY(r:  rational) 

WHERE  r.nua  »  x.nua  *  y.nua,  r.den  «  x.den  •  y.den 

MESSAGE  equal(x  y:  rational)  OPERATOR  ■ 

REPLY(b:  boolean) 

WHERE  b  <->  (x.nua  •  y.den  -  y.nua  *  x.den) 

END 
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S MAPLE  OUTPUT  2 


TYPE  rational 

INHERIT  equal ity{rat Iona  I } 

MODEL  (nun  den  :  Integer) 

INVARIANT  ALL(r  :  rational  ::  r.den  0) 

MESSAGE  ratlo(nun  den  :  Integer) 

WHEN  den  0 

REPLY  (r  :  rational) 

WHERE  r.nun  »  nun,  r.den  »  den 
OTHERWISE 

REPLY  EXCEPTION  zero_denon Inator 

MESSAGE  add(x  y  :  rational)  OPERATOR  + 

REPLY  (r  :  rational) 

WHERE  r.nun  «  x.num  •  y.den  +  y.nun  *  x.den,  r.den  ■  x.den  »  y.den 

MESSAGE  nultlply(x  y  :  rational)  OPERATOR  » 

REPLY  (r  :  rational) 

WHERE  r.nun  -  x.num  *  y.num,  r.den  *  x.den  *  y.den 

MESSAGE  equal(x  y  :  rational)  OPERATOR  - 
REPLY  (b  :  boolean) 

WHERE  b  <->  (x.num  •  y.den  «  y.nun  *  x.den) 

END 
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SAMPLE  INPUT  3 


MACHINE  air  I  inejsanagerjnterface  STATE  (?)  INVARIANT?  INITIALLY? 

MESSAGE  add_f  1 1  ght  ( I :  fllghtjd,  price:  ■oney,  origin  destination-,  airport, 
departure  arrival:  tine,  capacity:  nat)  WHEN  ?  —  new  flight  REPLY  done 
TRANSITION  ?  —  add  flight 
OTHERWISE  REPLY  EXCEPTION  f  I  Ight  exists 

MESSAGE  drop  fllght(l:  flight  Id)  WHEN  ?  —  flight  exists  REPLY  done 
TRANSITION  ?“—  rewove  flight"  OTHERWISE  REPLY  EXCEPTION  no_such_f 1 1 ght 
MESSAGE  new  fare(i:  fllghtjd,  price:  woney) 

WHEN  ?  —  flight  exists  REPLY  done  TRANSITION  ?  —  change  fare 

OTHERWISE  REPLY  EXCEPTION  no  such  flight 

END 
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SAMPLE  OUTPUT  3 


MACHINE  alrl lne_manager_interface 

STATE  (?) 

INVARIANT  ? 

INITIALLY  ? 

MESSAGE  add  f  1 1 ght ( i  :  fllghtjd,  price  :  money,  origin  destlnutlon 
departure  arrival  :  time,  capacity  :  nat) 

WHEN?  —new  flight 

REPLY  done 

TRANSITION?  —  add  flight 
OTHERWISE 

REPLY  EXCEPTION  f I  lght_exists 

MESSAGE  dropf light(l  :  fllght_ld) 

WHEN?  —  f  I  ight  exists 

REPLY  done 

TRANSITION?  —  remove  f 1  Ight 
OTHERWISE 

REPLY  EXCEPTION  no_such_f I Ight 

MESSAGE  new_fare( I  :  f I ightld,  price  :  money) 

WHEN?  —  flight  exists 

REPLY  done 

TRANSITION  ?  —  change  fare 
OTHERWISE 

REPLY  EXCEPTION  no_such_f I ight 
END 


! 


:  airport, 
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SAMPLE  INPUT  4 


MACHINE  sender  STATE(data:  sequencer  lock})  INVARIANT  true  INITIALLY 
MESSAGE  send(flle.-  sequence {block})  WHEN  length( file)  >  0 

SEND  f lrst(b:  block)  TO  receiver  WHERE  b  •  flie[1] 

TRANSITION  data  -  file 

OTHERWISE  REPLY  EXCEPTION  e«pty_flle 

MESSAGE  echo(b:  block) 

WHEN  b  -  *data[1]  &  length(*data)  >  1 

SEND  next(b1:  block)  TO  receiver  WHERE  bl  -  data[l] 

TRANSITION  ‘data  -  b  !i  data 

WHEN  b  -  *data[l]  &  length(*data)  -  1 

SEND  done  TO  receiver 

SEND  done  TO  sender 

TRANSITION  data  -  [  ] 

OTHERWISE  SEND  retransmlt(b2:  block)  TO  receiver  WHERE  b2  -  data[1] 

MESSAGE  done 

TRANSACTION  transfer  «  send  ;  DO  echo  OD  ;  done 


SAMPLE  OUTPUT  4 


MACHINE  sender 

STATE  (data  :  sequence {block}) 

INVARIANT  true 
INITIALLY  true 

MESSAGE  send(flle  :  sequencer  lock}) 

WHEN  length(file)  >  0 
SEND  f  I rst (b  :  block) 

TO  receiver 
WHERE  b  •  f  1  le[1] 

TRANSITION  data  -file 
OTHERWISE 

REPLY  EXCEPTION  empty_f 1  Is 

MESSAGE  echo(b  :  block) 

WHEN  b  -  *data[1]  &  length(*data)  >  1 
SEND  next(b1  :  block) 

TO  receiver 
WHERE  bl  -  data[  1  ] 

TRANSITION  «data  -  b  II  data 
WHEN  b  -  *data[1]  &  length(*data)  -  1 
SEND  done 
TO  receiver 
SEND  done 
TO  sender 

TRANSITION  data  -  [] 

OTHERWISE 

SEND  retransmits  :  block) 

TO  receiver 
WHERE  b2  «  data[1] 


MESSAGE  done 


TRANSACTION  transfer  «  send;  DO  echo  00 ;  done 
END 


I 
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SAMPLE  INPUT  5 


TYPE  char  INHERIT  equal lty{char)  INHERIT  total_order{char) 

MODEL (code :  nat)  —  ASCII  codes 
INVARIANT  All(C:  char  : :  0  <«  c.code  <«  127) 

MESSAGE  create(n:  nat)  —  literal  'a'  -  create(97)  and  so  on 
WHEN  0  <-  n  <-  127  REPLY(c:  char)  WHERE  c.code  -  n 
OTHERWISE  REPLY  EXCEPTION  lllegal_code 

MESSAGE  ordinal(c:  char)  REPLY(n:  nat)  WHERE  n  -  c.code 

MESSAGE  equal (cl  c2:  char)  REPLY(b:  boolean)  WHERE  b  <•>  (cl. code  .  c2.code) 

MESSAGE  less(ci  c2:  char)  R£PLY(b:  boolean)  WHERE  b  <->  (cl. code  <  c2.code) 

MESSAGE  I etter (c :  char)  REPLY(b:  boolean)  WHERE  b  «>  c  IN  ['a'  'z'1  |  c  IN 

['A'  ..  'Z'] 


MESSAGE  diglt(c:  char)  REPLY (b:  boolean)  WHERE  b  <«>  c  IN  ['O'  '9-] 

END 


184 


SAMPLE  OUTPUT  5 


TYPE  char 

INHERIT  equal ity(char) 

INHERIT  total_order{char} 

MODEL  (code  :  nat)  --  ASCII  codes 

INVARIANT  ALL(C  :  Char  : :  0  <■  C.COde  <»  127) 

MESSAGE  create(n  :  nat)  —  literal  'a'  «  create(97)  and  so  on 

WHEN  0  <-  n  <-  127 
REPLY  (C  :  char) 

WHERE  c.code  •  n 
OTHERWISE 

REPLY  EXCEPTION  i  I  lega I  code 

MESSAGE  ordlnal(c  :  char) 

REPLY  (n  :  nat) 

WHERE  n  -  c.code 

MESSAGE  equal(c1  c2  :  char) 

REPLY  (b  :  boolean) 

WHERE  b  <■>  (cl. code  -  c2.code) 

MESSAGE  Iess(c1  c2  :  char) 

REPLY  (b  :  boolean) 

WHERE  b  ««>  (cl. code  <  c2.code) 

MESSAGE  letter(c  :  char) 

REPLY  (b  :  boolean) 

WHERE  b  <->  c  IN  ['a'  ..  '2']  |  c  IN  ['A'  ..  'Z'] 

MESSAGE  dlgit(c  :  char) 

REPLY  (b  :  boolean) 

WHERE  b  <->  c  IN  [’O'  ..  '9'] 

END 
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SAMPLE  INPUT  6 


MACHINE  Inventory  —  assumes  that  shipping  and  supplier  are  other  modules. 

STATE (stock :  nap{ltea,  integer}) 

INVARIANT  ALL ( I :  Itea  ::  StOCk[l]  >-  0) 

INITIALLY  ALL ( I :  Itea  ::  stock[l]  -  0) 

MESSAGE  received:  itea,  q.-  integer)  —  Process  a  shlpaent  from  a  supplier. 
WHEN  q  >  0 

TRANSITION  stock[l]  -  *stock[l]  +  q 
--  Delayed  responses  to  backorders  are  not  shown  here. 

OTHERWISE  REPLY  EXCEPTION  eapty_shlpaent 

MESSAGE  order (lo:  Itea,  qo:  integer) 

--  Process  an  order  froa  a  customer. 

WHEN  0  <  qo  <-  stock[io] 

SEND  sh lp( is :  itea,  qs:  Integer)  TO  shipping  WHERE  Is  -  io,  qs  »  qo 
TRANSITION  stock[lo]  +  qo  «  •stock[io] 

WHEN  0  <  qo  >  stock[lo]  SEND  shlp(ls:  Itea.  qs:  Integer)  TO  shipping 
WHERE  is  -  lo,  qs  -  stock[io] 

SEND  back_order( lb:  Itea,  qb:  Integer)  TO  supplier 
WHERE  lb  -  lo,  qb  +  qs  -  qo 
TRANSITION  stock[lo]  -  0 
OTHERWISE  REPLY  EXCEPTION  empty  order 
END 
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SAMPLE  OUTPUT  6 


MACHINE  Inventory  —  assumes  that  shipping  and  supplier  are  other  modules. 


STATE  (stock  :  map(ltem,  Integer}) 

INVARIANT  ALL ( I  :  Item  ::  stOCk[i]  »  0) 

INITIALLY  ALL( I  :  Item  ::  stock[l]  -  0) 

MESSAGE  received  :  Item,  q  :  integer) 

—  Process  a  shipment  from  a  supplier. 

WHEN  q  >  0 

TRANSITION  Stock[l]  -  ‘stock! I ]  +  q 

—  Delayed  responses  to  backorders  are  not  shown  here. 

OTHERWISE 

REPLY  EXCEPTION  empty_shlpment 

MESSAGE  order(io  :  Item,  qo  :  Integer)  —  Process  an  order  from  a  customer. 

WHEN  0  <  qo  <-  stock! lo] 

SEND  sh lp( is  :  Item,  qs  :  Integer) 

TO  shipping 

WHERE  is  ■  io,  qs  -  qo 
TRANSITION  stock! io]  +  qo  -  ‘stock! lo] 

WHEN  0  <  qo  >  stock! io] 

SEND  shlp(ls  •.  Item,  qs  :  Integer) 

TO  shipping 

WHERE  is  ■  lo,  qs  »  stock! io] 

SEND  back_order(  lb  :  item,  qb  :  Integer) 

TO  suppl ler 

WHERE  ib  -  io,  qb  -r  qs  «  qo 
TRANSITION  stockUo]  -  0 
OTHERWISE 

REPLY  EXCEPTION  empty  order 
END 


187 


SAMPLE  INPUT  7 


VIRTUAL  TYPE  nunber{t:  type} 

INHERIT  equal lty{t} 

EXPORT  connutatlve  associative  distributive 
MODEL 

INVARIANT  true 
MESSAGE  zero 
REPLY(n:  t) 

MESSAGE  one 
REPLY(n:  t) 

MESSAGE  Plus(n1  n2:  t)  OPERATOR  + 

REPLY( 13:  t) 

WHERE  ALL(n :  t  ::  n  +  zero  ■  n),  connutat I ve(p lus) ,  assoc lat  I ve(p lus) 
MESSAGE  tl*es(n1  n2:  t)  OPERATOR  » 

REPL Y( 13:  t) 

WHERE  ALL(n:  t  ::  n  *  zero  -  zero), 

ALL(n:  t  : :  n  •  one  »  n), 

comnutatlve(tines),  assoc  lat  I  ve(  tines),  dlstrlbutlve(plus,  tines) 
CONCEPT  co«nutative(f :  FUNCTION) 

VALUE (b:  boolean) 

WHERE  b  <->  donaln(f)  -  [t,  t]  &  range(f)  -  t 
&  ALL(x  y:  t  ::  f(x,  y)  -  f(y,  z)) 

CONCEPT  associatlve(f :  FUNCTION) 

VALUE(b:  boolean) 

WHERE  b  <->  domaln(f)  -  [t,  t]  &  range(f)  -  t 
&  ALL(X  y  Z:  t  ::  f(X,  f(y,  Z))  -  f(f(X.  y),  Z)) 

CONCEPT  dlstr Ibut lve(f  g:  FUNCTION) 

VALUE(b:  boolean) 

WHERE  b  <->  donaln(f)  -  [t,  t]  &  range(f)  -  t 
&  donaln(g)  -  [t,  t]  &  range(g)  »  t 
&  ALL(x  y  z:  t  ::  g(x,  f(y,  z))  •  f(g(x,  y),  g(x,  z))) 

END 
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SAMPLE  OUTPUT  7 


VIRTUAL  TYPE  nu*ber(t  :  type} 

INHERIT  equal lty{t} 

EXPORT  coaautatlve  associative  distributive 
MODEL 

INVARIANT  true 

MESSAGE  zero 
REPLY  (0  :  t) 

MESSAGE  one 
REPLY  (n  :  t) 

MESSAGE  plus(n1  n2  :  t)  OPERATOR  + 

REPLY  (13  :  t) 

WHERE  ALL(n  :  t  ::  n  +  zero  «  n).  co«Butative(plus),  assoclat ive(plus) 

MESSAGE  tlaes(n1  n2  :  t)  OPERATOR  • 

REPLY  (13  :  t) 

WHERE  ALL(n  :  t  ::  n  *  zero  «  zero),  ALL(n  :  t  : :  n  •  one  •  n) , 

coninutatlve(tiaes),  assoclat  I  ve(t  lines),  d  i  str  I  but  I  ve(p  I  us ,  tines) 

CONCEPT  coanutatlve(f  :  FUNCTION) 

VALUE  (b  :  boolean) 

WHERE  b 

<->  doaain(f)  -  [t,  t]  &  range(f)  -  t 

5  ALL(x  y  :  t  : :  f(x,  y)  -  f(y,  Z)) 

CONCEPT  assoclatlve(f  :  FUNCTION) 

VALUE  (b  :  boolean) 

WHERE  b 

<->  doaain(f)  -  [t,  t]  &  range(f)  -  t 

6  ALL(x  y  z  :  t  ::  f(x,  f(y,  z))  -  f(f(x,  y),  z)) 

CONCEPT  d  IStr  I  but  I ve(f  g  :  FUNCTION) 

VALUE  (b  :  boolean) 

WHERE  b 

<->  doaain(f)  «  [t,  t]  &  range(f)  ■  t  &  doaain(g)  -  [t,  t] 

&  range(g)  «  t 

&  ALL(x  y  z  :  t  ::  g(x,  f(y,  z))  -  f(g(x,  y),  g(x,  z))) 
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SAMPLE  INPUT  8 


MACHINE  air  I lne_aanager 
INHERIT  foraat 

IMPORT  edit  fllghtjd  aoney  airport  tlae  FROM  travel_agent 
STATE 

INVARIANT  true 
INITIALLY  true 

MESSAGE  (coaaand:  string) 

—  coaaand  froa  airline  aanager's  keyboard 
WHEN  add  f  I  lght(ed It (coaaand),  I,  price,  origin,  destination, 
departure,  arrival,  capacity) 

SEND  addf  I  lght(  I :  f l Ightld,  price:  aoney.  origin  destination: 

departure  arrival:  tlae,  capacity:  nat) 

TO  air  I  Inereservat lonsystea 
WHEN  drop  f I lght(edlt(coaaand),  I) 

SEND  drop~fllght(l:  f  I  lght_id) 

TO  air  l  ine  reservatlon  systea 

WHEN  ne*_fare(edlt(coaaand),  I,  price) 

SEND  nee  fared:  flight  Id,  price:  aoney) 

TO  air l inereservation  systea 
OTHERWISE  REPLY(s:  string) 

WHERE  s  -  "coaaand  not  recognized" 

—  noraal  responses 

MESSAGE  done  SEND(S:  string)  TO  display  WHERE  s  -  "done" 

—  error  aessages 

—  input  foraats 

CONCEPT  addf  1 1  ght  (coaaand:  string,  I:  fllghtjd,  p:  aoney, 
o  d:  airport,  dep  arr:  tlae,  cn:  nat) 

VALUE(b:  boolean) 

WHERE  b  <■>  SOME (cap:  string  SUCH  THAT  cn  «  nat(cap)  ::  coaaand 
dep,  arr,  cap)  ) 

CONCEPT  drop  f  I  lght(coaaand:  string,  I:  fllghtjd) 

VALUE (b:  boolean) 

WHERE  b  <->  coaaand  -  listed",  I) 

CONCEPT  newJare(coaaand:  string,  i:  fllghtjd,  p:  aoney) 
VALUE(b :  boolean) 

WHERE  b  <»>  coaaand  «  listen",  I,  p) 

END 


airport. 


•  I  lst("a",  I ,  p,  o,  d. 
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SAkPLE  OUTPUT  8 


MACHINE  airline  Manager 
INHERIT  format 

IMPORT  edit  flightjd  Money  airport  t I ne 
FROM  travel_agent 

STATE 

INVARIANT  true 
INITIALLY  true 

MESSAGE  (coMmand  :  string)  —  command  from  airline  Manager's  keyboard 

WHEN  add_f I lght(edit(coMMand),  I.  price,  origin,  destination,  departure, 
arrival,  capacity) 

SEND  add_f  I  lght(  I  :  fllghtjd,  price  :  Money,  origin  destination 

:  airport,  departure  arrival  :  tlee,  capacity  :  nat) 
TO  airline  reservation  system 
WHEN  dropf I lght(edlt(command),  I) 

SEND  drop  f I ight(l  :  f  I  Ight  id) 

TO  alrllnereservatlonsystem 
WHEN  new_fare(edlt(coMMand) ,  I,  price) 

SEND  ne*»_fare(i  :  fllghtjd,  price  :  Money) 

TO  air  I Inereservationsystem 
OTHERWISE 

REPLY  (s  :  string) 

WHERE  s  «  "command  not  recognized"  —  normal  responses 


MESSAGE  done 

SEND  (s  :  string) 

TO  display 

WHERE  s  -  "done"  —  error  messages 
—  Input  formats 


CONCEPT  add  fl  lght(command  :  string,  I  :  fllghtjd,  p  :  money,  o  d  :  airport, 
dep  arr  ;  time,  cn  •.  nat) 

VALUE  (b  :  boolean) 

WHERE  b 

<->  SOME(cap  :  string  SUCH  THAT  cn  -  nat(cap) 

::  command  «  list(“a",  I,  p,  o,  d,  dep,  arr,  cap)) 

CONCEPT  drop  f I !ght( command  :  string,  I  :  fllght_ld) 

VALUE  (b  T  boolean) 

WHERE  b  <«>  command  »  llst("d",  I) 

CONCEPT  newja  re  (command  :  string,  I  :  fllght_id,  p  :  money) 

VALUE  (b“:  boolean) 

WHERE  b  <->  command  -  llst("n\  I,  p) 


191 


SAMPLE  INPUT  9 


TYPE  union{$S:  type}  WHERE  d 1st lnct( ident if lars(s)) 

—  A  union  type  is  a  tagged  disjoint  union  of  a  set  e*  types. 

—  Two  union  types  are  the  same  iff  they  have  the  same 

—  actual  parameters  WITH  THE  SAME  FIELD  NAMES. 

—  Ident i f lers(s)  Is  the  sequence  of  Identifiers  used  as 

—  field  names  in  the  actual  parameter  list. 

INHERIT  equal lty{unlon($s}} 

IMPORT  Identifiers  Identifier  FROM  field_names  IMPORT  distinct  FROM  sequence{ identifier} 

MODEL (tag :  Identifier,  value:  any) 

INVARIANT  ALL(u:  unlon{$s}  u.tag  IN  Ident  1  f  iers(s)), 

ALL(u:  unlon{$s}  ::  u. value  IN  type_of(u.tag)) 

MESSAGE  createfid:  identifier}  WHERE  id  IN  Ident if iers(s)  (x:  any) 

—  literal  {t  : :  v}  -  create{t}(v) 

WHEN  x  IN  typeof ( Id)  REPLY(u:  unlon{*s})  WHERE  u.tag  -  Id  &  u. value  «  x 

OTHERWISE  REPLY  EXCEPTION  type_error 

MESSAGE  i s ( id:  Identifier}  WHERE  Id  IN  Identif lers(s)  (u.-  oneof{$s}) 

REPLY (b :  boolean)  WHERE  b  <->  u.tag  ■■  Id 

—  Check  If  you  have  a  given  variant. 

MESSAGE  getcid:  identifier}  WHERE  Id  IN  Identif lers(s)  (u:  oneof{$s})  OPERATOR  . 

WHEN  u.tag  »  Id 

CHOOSE (rt:  type  SUCH  THAT  rt  -  typeof ( id)) 

REPLYfx:  rt)  WHERE  x  -  u. value 
OTHERWISE  REPLY  EXCEPTION  type_error 

—  Extract  the  value  assuming  a  given  variant, 

—  succeeds  only  if  the  tag  matches  the  assumed  variant. 

MESSAGE  equalful  u2:  union{Ss}) 

REPLY(b:  boolean) 

WHERE  b  <«>  ul.tag  «  u2.tag  &  ul. value  -  u2. value 

CONCEPT  type  of (Id:  Identifier) 

WHERE  Id  IN  identif iers(s) 

VALUE(t :  type) 

—  The  type  corresponding  to  the  id  In  the  formal  parameter  list  s. 

WHERE  S0ME(n:  nat  ::  t  •  s[n]  &  Id  -  Identif lers(s)[n]) 

END 


SAMPLE  OUTPUT  9 


TYPE  unlontSs:  type} 

WHERE  d  (st  I  net  ( I  dent  iflers(s)) 

—  A  union  type  Is  a  tagged  disjoint  union  of  a  set  of  types. 

—  Two  union  types  are  the  sane  Iff  they  have  the  sane 

—  actual  parameters  WITH  THE  SAME  FIELD  NAMES. 

—  I  dent  I f lers(s)  Is  the  sequence  of  Identifiers  used  as 

—  field  naaes  In  the  actual  parameter  list. 

INHERIT  equal lty(unlon{$s}} 

IMPORT  Identifiers  Identifier 
FROM  field  names 
IMPORT  distinct 

FROM  sequence{ Identifier) 

MODEL  (tag  :  Identifier,  value  :  any) 

INVARIANT  ALL(u  :  uniontSs)  ::  u.tag  IN  I  dent  ifiers(s)), 

ALL(u  :  unlon{$s)  ::  u. value  IN  type_of (u.tag)) 

MESSAGE  create(ld  :  Identifier) 

WHERE  Id  IN  I  dent  if lers(s) 

(x  :  any)  —  literal  (t  : :  v)  -  create(t)(v) 

WHEN  x  IN  type_of ( Id) 

REPLY  (u  :  unlon{$s}) 

WHERE  u.tag  -  Id  &  u. value  -  x 
OTHERWISE 

REPLY  EXCEPTION  type_error 

MESSAGE  Istid  :  Identifier) 

WHERE  Id  IN  identlf lers(s) 

(u  :  oneoffSs}) 

REPLY  (b  :  boolean) 

WHERE  b  <=>  u.tag  «  Id  --  Check  If  you  have  a  given  variant. 


MESSAGE  gettld  :  Identifier) 

WHERE  id  IN  Identlf lers(s) 

(u  :  oneoftSs})  OPERATOR  . 

WHEN  u.tag  -  Id 

CHOOSE (rt  :  type  SUCH  THAT  rt  -  type  of (Id)) 
REP1  v  (x  :  rt) 

WHERE  x  -  u. value 
OTHERWISE 

REPLY  EXCEPTION  type_error 

—  Extract  the  value  assuming  a  given  variant, 

—  succeeds  only  If  the  tag  matches  the  assumed  variant. 
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MESSAGE  equal(ul  u2  :  unlon{$s}) 

REPLY  (b  :  boolean) 

WHERE  b  <«>  ul.tag  -  u2.tag  &  ul. value  »  u2. value 

CONCEPT  type  of (Id  :  Identifier) 

WHERE  Id  In  I  dent  I f lers(s) 

VALUE  (t  :  type) 

--  The  type  corresponding  to  the  Id  In  the  foraal  paraneter  list  s. 

WHERE  S0ME(n  :  nat  ::  t  -  s[n]  &  Id  -  Idont If lers(s)[n)) 

END 
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SAMPLE  INPUT  10 


MACHINE  travel_agent_lnterface  IMPORT  flight  FROM  alrl ine_Banager_ interface 

STATE (reservations:  set(reservatlon),  schedule:  «ap{f I lght_ld,  flight}) 

I NVAR I  ANT  ex  I st I ng_f 1 1 ghts( reser vat  Ions),  no_overbook I ng ( reser vat  I ons ) 
INITIALLY  reservations  -  {  } 

MESSAGE  find  f I ights(orlgln  destination:  airport)  —  G1.1.1,  G1.1.2 
REPLY  fl,'ghts(s:  set{f light}) 

WHERE  ALL(f :  flight  ::  f  IN  s  <•>  f  IN  range(schedule)*.  f. origin  «  origin 

&  f .destination  -  destination  ) 

--  flights  from  the  origin  to  the  destination 
MESSAGE  reserve(l:  flightjd,  d:  date,  p:  passenger)  —  G1.2 
WHEN  l  IN  schedule  &  booklngs(l,  d)  <  schedule[ I]. capacity 

&  "([ Id: :  I,  d::  d,  p::  p]  IN  ‘reservations)  —  seat  available 
REPLY  done 

TRANSITION  reservations  -  ‘reservations  U  {[id::  I,  d::  d,  p::  p]} 

--  add  reservation 

WHEN  [Id::  I,  d::  d.  p::  p]  IN  ‘reservations 
REPLY  EXCEPTION  reservat lonexlsts 
WHEN  "(I  IN  schedule)  —  unknown  flight 
REPLY  EXCEPTION  no  such  flight 
OTHERWISE  REPLY  EXCEPT  I ON_no_seat 
MESSAGE  cance  1(1:  flightjd,  d:  date,  p-.  passenger)  —  G1.3 
WHEN  I  IN  schedule  &  [Id::  I,  d::  d,  p.-:  p]  IN  reservations 
--  reservation  found 
REPLY  done 

TRANSITION  reservations  •  ‘reservations  -  {[id::  I,  d::  d,  p::  p]} 

—  remove  reservation 
WHEN  "(I  IN  schedule)  --  unknown  flight 
REPLY  EXCEPTION  nosuch  flight 
OTHERWISE  REPLY  EXCEPT ION~no  jeservat Ion 
CONCEPT  existing  f I ights(s:  set(reservatlon)) 

VALUE(b:  boolean) 

where  ALL ( r :  reservation  SUCH  THAT  r  IN  s  ::  r. flightjd  IN  schedule) 
CONCEPT  no  overbook lng(s:  set(reservatlon)) 

VALUE(b.'boolean) 

WHERE  ALL( I :  fllght_ld,  d:  date  SUCH  THAT  I  IN  schedule 
::  bookingsd,  d)  <-  scheduled). capacity  ) 

CONCEPT  bookingsd:  flight  Id,  d:  date) 

VALUE(n:  nat) 

WHERE  n  -  NUMBER(r:  reservation 

SUCH  THAT  r  IN  reservations  &  r.  id  »  i  &  r.d  «  d  ::  r  ) 

CONCEPT  reservation:  type 

WHERE  reservation  -  tupledd::  flightjd,  d::  date,  p::  passenger} 


END 


SAMPLE  OUTPUT  10 


MACHINE  travel  agent  Interface 
IMPORT  flight 

FROM  airl  ine_«anagerjnterface 

STATE  (reservations  :  set{reservatlon},  schedule  :  sap{f  I  Ightjd,  flight}) 
INVARIANT  exist lng_f I lghts(reservat Ions),  no_overbooklng(reservat ions) 
INITIALLY  reservations  -  {} 

MESSAGE  f lnd_f I lghts(orlgln  destination  :  airport)  —  G1.1.1,  61.1,2 

REPLY  f I lghts(s  :  set(f light}) 

WHERE  ALL ( f  :  flight 
::  f  IN  s 

<->  f  IN  range(schedule)  &  f. origin  «  origin 
&  f .destination  -  destination) 

—  flights  froe  the  origin  to  the  destination 


MESSAGE  reserved  :  flight  id,  d  :  date,  p  :  passenger)  —  G1.2 

WHEN  l  IN  schedule  &  booklngs(l,  d)  <  schedulet I ]. capacity 

&  ‘([Id  ::  I,  d  d,  p  ::  p]  IN  ‘reservations)  —  seat  available 

REPLY  done 

TRANSITION  reservations  -  ‘reservations  U  {[Id  ::  I,  d  d,  p  p]} 

—  add  reservation 

WHEN  [ Id  : :  I ,  d  : :  d,  p  : p]  IN  ‘reservations 
REPLY  EXCEPTION  reservat ion  exlsts 
WHEN  "(i  IN  schedule)  —  unknown  flight 

REPLY  EXCEPTION  nosuch  flight 
OTHERWISE 

REPLY  EXCEPTION  no_seat 

MESSAGE  cancel  (I  :  f  I  Ightjd,  d  :  date,  p  :  passenger)  —  G1.3 

WHEN  I  IN  schedule  &  [id  ::  l,  d  ::  d,  p  ::  p)  IN  reservations 

—  reservation  found 

REPLY  done 

TRANSITION  reservations  »  ‘reservations  -  {[Id  ::  I,  d  ::  d,  p  ::  p]} 

—  renove  reservation 

WHEN  *(l  IN  schedule)  —  unknown  flight 

REPLY  EXCEPTION  no  such  flight 
OTHERWISE 
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REPLY  EXCEPTION  no  reservation 


CONCEPT  ex  I st 1 ng_f  t lghts($  :  set{reservatlon}) 

VALUE  (b  :  boolean) 

WHERE  ALL ( r  :  reservation  SUCH  THAT  r  IN  s  ::  r. flight  Id 

CONCEPT  no_overbooklng(s  :  set{reservatlon}) 

VALUE  (b  :  boolean) 

WHERE  ALL(I  :  fllghtjd,  d  :  date  SUCH  THAT  I  IN  schedule 
::  booklngs(l,  d)  <«  schedule[l]. capacity) 

CONCEPT  booklngsd  :  flight  Id,  d  :  date) 

VALUE  (n  :  nat) 

WHERE  n 

■  NUMBER(r  :  reservation 

SUCH  THAT  r  IN  reservations  &  r.ld  -  i  &  r. 

CONCEPT  reservation:  type 

WHERE  reservation  -  tuple(ld  ::  flight  id,  d  ::  date,  p  :• 
END 


IN  schedule) 


d-d  ::  r) 

passenger) 


198 


SAMPLE  INPUT  11 


TYPE  real 

INHERIT  nuaber{real} 

INHERIT  total_order{real) 

MODEL 

INVARIANT  true 

MESSAGE  ratlonal_to_real(r1:  rational) 

--  type  conversion  operation  for  fixed  eode  aritheetlc 
REPLY(r2:  real) 

WHERE  ratlonal  to  real(zero)  -  zero,  ratlonal  to  real(one)  -  one, 
ALL(x  y:  rational  ::  rational_to_real(x  -  y)  -  ratlonal_to_real(x) 
ratlonal_to_real(y)), 

ALL(x  y:  rational  SUCH  THAT  y  zero  ::  ratlonal_to_real(x  /y)- 
rat  lonaltoreal(x)  /  rat  I ona  I _t.o_rea  I  (y ) ) 

MESSAGE  lnteger_to_real(l:  Integer) 

—  type  conversion  operation  for  aixed  aode  arlthaetlc 
REPLY(r:  real) 

WHERE  r  «  rat lonal_to_real(lnteger_to_ratlonal*rat Iona  1(1)) 

MESSAGE  nat_to_real(n:  nat) 

--  type  conversion  operation  for  aixed  aode  arlthaetlc 
REPLY(r :  real) 

WHERE  r  -  ratlonal_to_real(nat_to_ratlonalfratlonal(n)) 

MESSAGE  rat  Iona  I  (r:  real) 

REPLY(b:  boolean) 

WHERE  S0ME( I :  Integer  ::  r  -  ratlonal_to_real( I)) 

MESSAGE  Integra  I  (r:  real) 

REPLY (b :  boolean) 

WHERE  SOME ( I :  Integer  ::  r  -  Integer  to  reaK I)) 

MESSAGE  nat(r:  real) 

REPLY(b:  boolean) 

WHERE  SOME(n:  nat  ::  r  -  nat  to  real(n)) 

MESSAGE  zero 
—  I Iteral  0.0  »  zero 
REPLY ( I :  real) 

MESSAGE  one 
—  I  Iteral  1.0  -  one 
REPLY ( I :  real) 

MESSAGE  alnusfrl:  real)  OPERATOR  - 
REPLY ( r 2 :  real) 


WHERE  r2  -  0.0  -  rl 


MESSAGE  plus(r1  r2:  real)  OPERATOR  + 

REPLY ( r3 :  real) 

MESSAGE  differences  r2:  real)  OPERATOR  - 
REPLY(r3:  real) 

WHERE  rl  -  r2  +  r3 

MESSAGE  tl«es(rl  r2:  real)  OPERATOR  * 

REPLY(r3:  real) 

MESSAGE  quotlent(r1  r2:  real)  OPERATOR  / 

WHEN  r2  zero 
REPLY(r3:  real) 

WHERE  rl  -  r2  •  r3 

OTHERWISE  REPLY  EXCEPTION  dlvlde_by_zero 

MESSAGE  reaalnder(r1  r2:  real)  OPERATOR  \  MOD 
WHEN  r2  zero 
REPLY ( r :  real) 

WHERE  SOM£(q:  real  ::  rl  «  q  •  r2  +  r  &  abs(r2)  >  r  >»  zero  &  Integra  I (Q)) 
OTHERWISE  REPLY  EXCEPTION  dlvldebyzero 

MESSAGE  expt(r1  r2:  real)  OPERATOR  •• 

WHEN  (rl  -  0.0  &  r2  <-  0.0)  j  (rl  <  0.0  &  "Integra I (r2)) 

REPLY  EXCEPTION  undefined  expt 
OTHERWISE  REPLY(r3:  real) 

WHERE  ALL(r :  real  ::  r  •*  1.0  «  r),  ALL ( r :  real  SUCH  THAT  r  >  0.0  ::  0.0 
*•  r  -  0.0), 

ALL(r  x  y:  real  SUCH  THAT  r  >  0.0  !  r  <  0.0  &  Integral(x)  &  Integral(y) 

::  r  ••  (x  +  y)  -  (r  ••  x)  •  (r  ••  y)  ) 

MESSAGE  equaKrl  r2:  real) 

REPLY (b :  boolean) 

MESSAGE  Iess(r1  r2:  real) 

REPLY(b:  boolean) 

WHERE  ALL(x  y:  rational  ::  ratlonal_to_real(x)  <  ratlonal_to_real(y)  <»>  x  <  y), 

ALL(x  y  z:  real  ::  x  +  y  <  x  +  z  «->  y  <  z), 

ALL(X  y  Z:  real  SUCH  THAT  X  >  0.0  : :  X  •  y  <  X  *  Z  <->  y  <  z) , 

ALL(x  y  Z:  real  SUCH  THAT  X  <  0.0  ::  X  •  y  <  X  •  Z  <->  y  >  z) 


200 


SAMPLE  OUTPUT  11 


TYPE  real 

INHERIT  nueber{real} 

INHERIT  total_order{real) 

MODEL 

INVARIANT  true 

MESSAGE  ratlonal_to_real(r1  :  rational) 

--  type  conversion  operation  for  alxed  aode  arlthaetlc 

REPLY  (r2  :  real) 

WHERE  ratlonal_to_real(zero)  -  zero,  ratlonal_to_real(one)  »  one, 
ALL(x  y  :  rational 

: :  ratlonal_to_real(x  -  y) 

-  ratlonal_to_real(x)  -  rat  Iona l_to_rea I (y)) , 

ALL ( x  y  :  rational  SUCH  THAT  y  zero 
::  ratlonal_to_real(x  /  y) 

■  ratlonal_to_real(x)  /  rat  I ona I _to_rea I (y ) ) 

MESSAGE  lnteger_to_real( I  :  Integer) 

—  type  conversion  operation  for  alxed  aode  arlthaetlc 

REPLY  (r  :  real) 

WHERE  r  -  rat  I ona I torea I ( I nteger_to_rat I ona lirat I ona 1(1)) 

MESSAGE  nat_to_real(n  :  nat) 

—  type  conversion  operation  for  alxed  aode  arlthaetlc 

REPLY  (r  :  real) 

WHERE  r  ■  rational_to_real(nat_to_ratlonaltratlonal(n)) 

MESSAGE  rat  Iona  I (r  :  real) 

REPLY  (b  :  boolean) 

WHERE  SOME ( I  :  Integer  ::  r  -  rat  Iona  I _to_rea 1(1)) 

MESSAGE  Integra  I  (r  :  real) 

REPLY  (b  :  boolean) 

WHERE  SOMEC I  :  Integer  ::  r  ■  lnteger_to_real(l)) 

MESSAGE  nat(r  :  real) 

REPLY  (b  :  boolean) 

WHERE  S0ME(n  :  nat  : :  r  -  nat_to_real(n)) 

MESSAGE  zero  --  literal  0.0  -  zero 
REPLY  (I  :  real) 

MESSAGE  one  —  literal  1.0  -  one 
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REPLY  (I  :  real) 


MESSAGE  alnusS  :  real)  OPERATOR  - 
REPLY  (r2  :  real) 

WHERE  r2  -  0.0  -  rl 

MESSAGE  plus(r1  r2  :  real)  OPERATOR  + 

REPLY  (r3  :  real) 

MESSAGE  differences  r2  :  real)  OPERATOR  - 
REPLY  (r3  :  real) 

WHERE  rl  -  r2  +  r3 

MESSAGE  tlnesS  r2  :  real)  OPERATOR  • 

REPLY  (r3  :  real) 

MESSAGE  quot I*nt(r1  r2  :  real)  OPERATOR  / 

WHEN  r2  zero 
REPLY  (r3  :  real) 

WHERE  rl  -  r2  •  r3 
OTHERWISE 

REPLY  EXCEPTION  dlvlde_by_zero 

MESSAGE  reaainder(r1  r2  :  real)  OPERATOR  MOD  MOD 
WHEN  r2  "«  zero 
REPLY  (r  :  real) 

WHERE  SOME(q  :  real 

::  rl  •  q  •  r2  +  r  &  abs(r2)  »  r  >-  zero  &  Integra  I  (q) ) 

OTHERWISE 

REPLY  EXCEPTION  d I vldebyzero 

MESSAGE  expt ( r 1  r2  :  real)  OPERATOR  •• 

WHEN  (rl  -  0.0  &  r2  <-  0.0)  !  (rl  <  0.0  &  ~ Integra l( r 2) ) 

REPLY  EXCEPTION  undef Inedexpt 
OTHERWISE 

REPLY  ( r 3  :  real) 

WHERE  ALL(r  :  real  ::  r  ••  1.0  »  r), 

ALL(r  :  real  SUCH  THAT  r  >  0.0  ::  0.0  ••  r  -  0.0), 

ALL(r  x  y  :  real 

SUCH  THAT  r  »  0.0  !  r  <  0.0  &  Integra  I (x)  &  Integra  I (y) 
::  r  ••  (X  +  y)  -  (r  ••  x)  •  (r  ••  y)) 

MESSAGE  equals  r2  :  real) 

REPLY  (b  :  boolean) 

MESSAGE  lessS  r2  :  real) 

REPLY  (b  :  boolean) 

WHERE  ALL(x  y  :  rational 

::  rat  Iona  I _to_rea I (x)  <  rational  to_real(y)  <*>  x  <  y), 

ALL (x  y  z  :  real  ::  x  ♦  y  <  x  +  z  <»>  y  <  z), 
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ALL (x  y  z  :  real  SUCH  THAT  x  >  0.0  : :  x  *  y  <  x  •  z  <->  y  <  z), 
ALL (x  y  z  :  real  SUCH  THAT  x  <  0.0  : :  x  •  y  <  x  •  z  <«>  y  >  z) 
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SAMPLE  INPUT  12 


W 


TYPE  coaplex  INHERIT  nuaber(coaplex} 

M0DEL(re  la:  real) 

INVARIANT  true 

MESSAGE  real_to_coaplex(r:  real) 

--  type  conversion  operation  for  aixed  aode  arlthaetic 
REPLY (c:  coaplex) 

WHERE  c.re  -  r,  c.la  -  0.0 
MESSAGE  ratlonal_to_coaplex(r:  rational) 

--  type  conversion  operation  for  aixed  aode  arlthaetic 
REPLY(c:  coaplex) 

WHERE  c  -  real_to_coaplex(ratlonal_to_realareal(r)) 
MESSAGE  lnteger_to_coaplex(l:  Integer) 

—  type  conversion  operation  for  aixed  aode  arlthaetic 
REPLY(c:  coaplex) 

WHERE  c  »  reai_to_coaplex(lnteger_to_realtreal(l)) 
MESSAGE  nat_to_coaplex(n:  nat) 

—  type  conversion  operation  for  aixed  aode  arlthaetic 
REPLY(c:  coaplex) 

WHERE  c  -  real_to_coaplex(nat_to_realireal(n)) 

MESSAGE  real(c:  coaplex) 

REPLY(b:  boolean) 

WHERE  b  <->  c.la  -  0.0 

MESSAGE  laaglnary(c;  coaplex) 

REPLY(b:  boolean) 

WHERE  b  <•>  c.re  -  0.0 

MESSAGE  rat  Iona  I (c:  coaplex) 

REPLY(b:  boolean) 

WHERE  S0ME(r :  rational  ::  c  «  ratlonal_to_coaplex(r)) 

MESSAGE  Integra  1 (c:  coaplex) 

REPLY(b:  boolean) 

WHERE  SOME ( I :  Integer  ::  c  -  lnteger_to_coaplex( I )) 

MESSAGE  nat(c:  coaplex) 

REPLY(b:  boolean) 

WHERE  S0ME(n:  nat  ::  c  -  nat_to_coaplex(n)) 

MESSAGE  zero 
REPLY(C:  coaplex) 

WHERE  c  -  real_to_coaplex(0.0) 

MESSAGE  one 

REPLY(c:  coaplex) 

WHERE  c  -  real  to  coaplex(I.O) 

MESSAGE  I 
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REPLY (c :  coaplex) 

WHERE  I  •  I  -  -  one 

MESSAGE  conjugated! :  coaplex) 

REPLY (c2 :  coaplex) 

WHERE  c2.re  -  cl. re,  c2.la  «  -cl. la 

MESSAGE  aagnltude(c1 :  coaplex) 

REPLY(r :  real) 

WHERE  r  -  (c.re  ••  2  +  c.la  ••  2)  ••  0.5 

MESSAGE  alnus(c1:  coaplex)  OPERATOR  - 
REPLY(c2:  coaplex) 

WHERE  C2  -  0.0  -  c) 

MESSAGE  plus(c1  c2:  coaplex)  OPERATOR  + 

REPLY(c3:  coaplex) 

WHERE  c3.re  -  cl. re  +  c2.re,  c3.la  -  cl. la  +  c2.la 

MESSAGE  dlfference(c1  c2:  coaplex)  OPERATOR  - 
REPLY(c3:  coaplex) 

WHERE  cl  -  C2  +  c3 

MESSAGE  tlaes(c1  c2:  coaplex)  OPERATOR  • 

REPLY(c3:  coaplex) 

WHERE  c3.re  -  cl. re  •  c2.re  -  cl. la  •  c2.la, 
c3.la  -  cl. re  *  c2.la  ♦  cl. la  •  c2.re 

MESSAGE  quotlent(c1  c2:  coaplex)  OPERATOR  / 

WHEN  c2  '■  zero 
REPLY(c3:  coaplex) 

WHERE  cl  -  c2  *  c3 

OTHERWISE  REPLY  EXCEPTION  dlvlde_by_zero 

MESSAGE  expt(c1  c2:  coaplex)  OPERATOR  •• 

WHEN  (cl  •  zero  &  c2.re  <»  0.0) 

REPLY  EXCEPTION  undefined  expt 
OTHERWISE  REPLY(c3:  coaplex) 

WHERE  ALL(C:  coaplex  : :  c  ••  one  «  c),  ALL (c :  coaplex  SUCH  THAT  c.re  >  0. 
••  c  •  zero), 

ALL(c  x  y:  coaplex  SUCH  THAT  c  zero 

::  C  *•  (x  +  y)  -  (c  ••  x)  •  (c  ••  y)  ) 

MESSAGE  equal (cl  c2:  coaplex) 

REPLY(b:  boolean) 

WHERE  b  <«>  cl. re  *  c2.re  &  cl. la  -  c2.la 
END 


0  : :  zero 
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SAMPLE  OUTPUT  12 


TYPE  complex 

INHERIT  nuaber{coaplex) 

MODEL  (re  la  :  real) 

INVARIANT  true 

MESSAGE  real_to_coaplex(r  :  real) 

--  type  conversion  operation  for  alxed  aode  arithmetic 

REPLY  (c  :  complex) 

WHERE  c.re  -  r,  c.la  -  0.0 

MESSAGE  ratlonal_to_coaplex(r  :  rational) 

—  type  conversion  operation  for  alxed  aode  arithmetic 

REPLY  (c  :  complex) 

WHERE  c  «  real_to_complex(rational_to_reaiereal(r)) 

MESSAGE  integer_to_coaplex( I  :  Integer) 

--  type  conversion  operation  for  alxed  aode  arithmetic 

REPLY  (c  :  coaplex) 

WHERE  c  -  real_to_complex(lnteger_to_realtreal(l)) 

MESSAGE  nat_to_coaplex(n  :  nat) 

—  type  conversion  operation  for  alxed  aode  arithmetic 

REPLY  (c  :  complex) 

WHERE  c  -  real_to_coaplex(nat_to_real#real(n)) 

MESSAGE  real(c  :  coaplex) 

REPLY  (b  :  boolean) 

WHERE  b  <->  c.la  -  0.0 

MESSAGE  lmaglnary(c  :  complex) 

REPLY  (b  :  boolean) 

WHERE  b  «->  c.re  -  0.0 

MESSAGE  rat  Iona  I (c  :  coaplex) 

REPLY  (b  :  boolean) 

WHERE  S0ME(r  :  rational  ::  c  »  ratlonalto  complex(r)) 

MESSAGE  Integra  I (c  :  coaplex) 

REPLY  (b  :  boolean) 

WHERE  S0ME(l  :  Integer  c  ■  lnteger_to_coaplex( I )) 

MESSAGE  nat(c  :  coaplex) 

REPLY  (b  :  boolean) 
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WHERE  SOME(n  :  nat  ::  c  *  nat_to  coaplex(n)) 

MESSAGE  zero 

REPLY  (c  :  complex) 

WHERE  c  »  real_to_coaplex(0.0) 

MESSAGE  one 

REPLY  (c  :  coaplex) 

WHERE  c  ■  real_to_coaplex(1 .0) 

MESSAGE  I 

REPLY  (c  :  coaplex) 

WHERE  1*1-  -one 

MESSAGE  conjugated  coaplex) 

REPLY  (c2  :  coaplex) 

WHERE  c2.re  «  cl. re,  c2.la  -  -cl. la 

MESSAGE  aagnltude(c1  :  complex) 

REPLY  (r  :  real) 

WHERE  r  -  (c.re  ••  2  +  c.la  •*  2)  ••  0.5 

MESSAGE  alnus(cl  :  coaplex)  OPERATOR  - 
REPLY  (c2  :  coaplex) 

WHERE  C2  -  0.0  -  cl 

MESSAGE  plus(c1  c2  :  complex)  OPERATOR  + 

REPLY  (c3  :  complex) 

WHERE  c3.re  -  cl. re  +  c2.re,  c3.la  «  cl. la  +  c2.lm 

MESSAGE  dlfference(c1  c2  :  coaplex)  OPERATOR  - 
REPLY  (c3  :  coaplex) 

WHERE  cl  -  c2  +  c3 

MESSAGE  tlaes(c1  c2  :  coaplex)  OPERATOR  • 

REPLY  (c3  :  complex) 

WHERE  c3.re  -  cl. re  *  c2.re  -  cl. la  *  c2.im, 
c3.la  »  cl. re  *  c2.ia  +  cl. la  *  c2.re 

MESSAGE  quotient (cl  c2  :  coaplex)  OPERATOR  / 

WHEN  c2  "«  zero 

REPLY  (c3  :  complex) 

WHERE  cl  -  c2  •  c3 
OTHERWISE 

REPLY  EXCEPTION  dl vlde_by_zero 

MESSAGE  expt(c1  c2  :  coaplex)  OPERATOR  •• 

WHEN  (cl  «  zero  &  c2.re  <-  0.0) 

REPLY  EXCEPTION  undefined  expt 
OTHERWISE 

REPLY  (c3  :  coaplex) 
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WHERE  ALL(c  :  complex  ::  c  •*  one  «  c), 

ALL(C  :  complex  SUCH  THAT  c.re  >0.0  ::  2ero  *• 
ALL (c  x  y  :  coap lex  SUCH  THAT  c  '»  zero 
::  c  •*  (x  +  y)  «  (c  **  x)  •  (c  **  y)) 


END 


MESSAGE  equal (cl  c2  :  complex) 

REPLY  (b  :  boolean) 

WHERE  b  <«>  cl. re  »  c2.re  4  cl.lt  -  c2.l« 


c  «  zero) 
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SAMPLE  INPUT  13 


TYPE  sequencer :  type} 

INHERIT  equal ity{sequence{t}} 

INHERIT  total_order{sequence{t}} 

EXPORT  sorted  distinct  permutation  frequency 
MODEL 

--  generated  by  {empty,  add} 

INVARIANT  true 

MESSAGE  empty 

—  I Iteral  [  ]  -  empty 
REPLY(s:  sequence{t}) 

MESSAGE  add(x:  t,  si:  sequence{t}) 

—  literal  [x]  -  add(x,  empty) 

—  literal  [x,  $s]  -  add(x,  s) 

REPLY (s2:  sequence{t}) 

MESSAGE  remove(x:  t,  si.-  sequence{t}) 

—  Remove  all  Instances  of  x  from  s. 

REPLY (s2 :  sequence{t}) 

WHERE  ALL(x:  t  ::  remove(x,  empty)  -  empty), 

ALL(X:  t,  s:  sequence{t}  ::  remove(x,  add(x,  s))  -  remove(x,  s)), 
ALL(x  y:  t,  s:  sequence{t}  SUCH  THAT  x  y 
::  remove(x,  add(y,  s))  -  add(y,  remove(x,  s))  ) 

MESSAGE  append(s1  s2:  sequence{t})  OPERATOR  !! 

—  literal  [Ssl,  $s2]  -  appendfsl,  s2) 

REPLY(s2:  sequenceft}) 

WHERE  ALL(s:  sequenceft}  ::  appendfempty,  s)  «  s), 

ALL(x:  t,  si  s2:  sequenceft} 

::  append{add(x,  si),  s2)  •  add(x,  append(s1,  s2))  ) 

MESSAGE  fetches:  sequenceft},  n:  nat)  OPERATOR  [ 

—  fetchfs,  n)  «  s{n} 

WHEN  1  <-  n  <-  length(s) 

REPLY(X:  t) 

WHERE  ALL(x:  t,  s:  sequence{t}  ::  fetch(add(x,  s),  1)  «  x), 

ALL(n:  nat,  x:  t,  s:  sequenceft}  SUCH  THAT  n  >  1 
::  fetch(add(x,  s),  n)  -  fetch(s,  n  -  1)  ) 

OTHERWISE  REPLY  EXCEPTION  bounds_error 

MESSAGE  fetchfsl:  sequence{t},  s2:  sequence{nat})  OPERATOR  [ 
REPLY(s3:  sequence{t}) 

WHERE  Iength(s3)  -  Iength(s2), 

ALL(n:  nat  SUCH  THAT  n  IN  domaln(s2)  ::  s3[n]  -  s1[s2[n]]) 

MESSAGE  length(s:  sequenceft}) 

REPLY (n :  nat) 
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WHERE  length(eapty)  -  0, 

ALL ( x :  t,  s:  sequences)  ::  length(add(x,  s))  ■  length(s)  +  1) 

MESSAGE  do*aln(s:  sequence(t)) 

REPLY (d :  set{nat}) 

WHERE  d  -  {1  ..  length(s)} 

MESSAGE  aeaber(x:  t,  S:  sequence(t))  OPERATOR  IN 
REPLY(b:  boolean) 

WHERE  b  <->  SOME ( n :  nat  SUCH  THAT  n  IN  doaain(s)  ::  s[n]  -  x) 

MESSAGE  equal($1  s2:  sequence(t)) 

REPLY(b:  boolean) 

WHERE  b  <->  ALL(n:  nat  ::  s1[n]  -  s2[n]) 

MESSAGE  Iess(s1  s2:  sequence(t)) 

--  lexicographic  ordering  (dictionary  ordering  on  strings) 

WHEN  has  operations,  less)  &  partial  orderlng(lesset) 

REPLY (b:  boo  lean) 

WHERE  ALL(s:  sequence(t).  x=  t  :.-  [  ]  <  [x.  Is]). 

ALL ( s 1  s2:  sequence(t),  xl  x2:  t 

::  [xl,  $S1]  <  [X2,  Is2]  <->  xl  <  x2  xl  «  x2  &  si  <  s2  ) 

OTHERWISE  REPLY  EXCEPTION  operatlon_not_app! Icable 

MESSAGE  subsequence (si  s2:  sequence(t)) 

REPLY(b:  boolean) 

--  True  If  the  eleaents  of  si  are  eabedded  In  s2,  in  the  saae  order. 
WHERE  ALL(S:  sequence(t)  ::  subsequence([  ],  s)), 

ALL(sl  s2:  sequence(t),  x:  t  ::  subsequence([x,  Isl],  s2) 

<»>  S0ME(s3  s 4:  sequence(t) 

::  s2  •  [$s3,  x,  Is4]  &  subsequence(s1 ,  s4)  )) 

MESSAGE  IntervaKxl  x2:  t)  OPERATOR  .. 

WHEN  subtype(t,  totalorder) 

REPLY (s:  sequence(t)) 

WHERE  sorted(less)(s)  &  ALL(X:  t  : :  x  IN  s  <«»  xl  x  <«  x2) 
OTHERWISE  REPLY  EXCEPTION  operat ion_not_appl Icable 

MESSAGE  apply(f :  FUNCTION,  si:  sequence(t}) 

WHEN  doaain(f)  -  [t] 

CHOOSE (rt :  type  SUCH  THAT  rt  -  range(f)) 

REPLY(s2:  sequence{rt)) 

WHERE  Iength(s2)  -  length(sl), 

ALL(n:  nat  SUCH  THAT  n  IN  doaaln(sl)  ::  s2[n]  -  f(s1[n])) 

OTHERWISE  REPLY  EXCEPTION  typeerror 

MESSAGE  reduce{f :  FUNCTION) 

WHERE  doaain(f)  -  [t.  t]  &  range(f)  -  t 
&  SOME(X:  t  ::  ALL (y :  t  ::  f (y.  X)  -  y)) 

(s:  sequence(t)) 

REPLY(x:  t) 
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WHERE  IF  S  -  [  ]  THEN  ALL (y :  t  ::  f(y,  X)  -  y) 

ELSE  x  -  f(s[1],  reduce(s[2  ..  length(s)],  f))  FI 

CONCEPT  sortedde:  FUNCTION)  WHERE  total_order lng( le) 

(s:  sequence(t)) 

VALUE (b :  boolean) 

WHERE  b  <->  ALL (n 1  n2:  nat  SUCH  THAT  1  <-  nl  <  n2  <-  length(s) 
::  le(s[n1],  s[n2))  ) 

CONCEPT  d 1st  I net (s:  seguence{t)) 

VALUE ( b :  boolean) 

WHERE  b  <->  ALL (nl  n2:  nat  SUCH  THAT  1  <-  nl  <  n2  <-  length(s) 
::  s[n1)  s[n2]  ) 

CONCEPT  perwutatlon(s1  s2:  sequence(t)) 

VALUE (b :  boolean) 

WHERE  b  <->  ALL(x:  t  ::  f requency(x,  si)  -  frequency(x,  s2)) 

CONCEPT  frequency(x:  t,  s:  sequence(t)) 

VALUE (n:  nat) 

WHERE  n  -  NUMBER (k:  nat  SUCH  THAT  s[k]  -  X  ::  k) 

END 
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SAMPLE  OUTPUT  13 


TYPE  sequencer  :  type} 

INHERIT  equal lty(sequence{t}} 

INHERIT  total_order{sequence{t}} 

EXPORT  sorted  distinct  perautatlon  frequency 

MODEL  —  generated  by  (eapty,  add} 

INVARIANT  true 

MESSAGE  eapty  —  literal  [  ]  -  eapty 
REPLY  (s  :  sequence{t}) 

MESSAGE  add(x  :  t,  si  :  sequenceft})  —  literal  [x]  -  add(x,  eapty) 

--  literal  [x,  $s]  «  add(x,  s) 

REPLY  (s2  :  sequenceft}) 

MESSAGE  reaove(x  :  t,  si  :  sequencer }) 

—  Reaove  all  Instances  of  x  froa  s. 

REPLY  (s2  :  sequence{t}) 

WHERE  ALL(x  :  t  ::  reaove(x,  eapty)  -  eapty), 

ALL(x  :  t,  s  :  sequenceft} 

::  reaove(x,  add(x,  s))  -  re»ove(x,  s)), 

ALL(x  y  :  t,  s  :  sequence{t}  SUCH  THAT  x  *-  y 

::  reaovefx,  add(y,  s))  -  add(y,  reaovefx,  s))) 

MESSAGE  append (si  s2  :  sequence{t})  OPERATOR  J| 

—  literal  [$sl,  $s2]  -  append(sl,  s2) 

REPLY  (s2  :  sequence{t}) 

WHERE  ALL(s  :  sequence{t}  ::  append(eapty,  s)  -  s), 

ALL(x  :  t,  si  s2  :  sequence{t} 

::  append(add(x,  si),  s2)  -  add(x,  append(s1,  s2))) 

MESSAGE  fetch(s  :  sequence(t},  n  :  nat)  OPERATOR  [  —  fetch(s,  n)  -  s[n] 

WHEN  1  <«  n  <«  length(s) 

REPLY  (X  :  t) 

WHERE  ALL(x  :  t,  s  :  sequence{t}  ::  fetch(add(x,  s),  1)  -  x), 
ALL(n  :  nat,  x  :  t,  s  :  sequenceft}  SUCH  THAT  n  >  1 
::  fetch(add(x,  s),  n)  -  fetch(s,  n  -  1)) 

OTHERWISE 

REPLY  EXCEPTION  bounds_error 

MESSAGE  fetch(s1  :  sequence{t},  s2  :  sequencefnat})  OPERATOR  [ 

REPLY  (s3  :  sequence{t}) 
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WHERE  Iength(s3)  -  Iength(s2). 

ALL(n  :  nat  SUCH  THAT  n  IN  domain(s2)  ::  s3[n]  -  sl[s2[n]]) 

MESSAGE  length(s  :  sequence(t)) 

REPLY  (n  :  nat) 

WHERE  length(empty)  -  0, 

ALL(x  :  t,  s  :  sequence(t)  ::  length(add(x,  s))  -  length(s)  +  1) 

MESSAGE  doialn(s  :  sequence(t)) 

REPLY  (d  :  set {nat}) 

WHERE  d  -  {1  ..  length(s)} 

MESSAGE  ee»ber(x  :  t,  s  :  sequence(t))  OPERATOR  IN 
REPLY  (b  :  boolean) 

WHERE  b  <->  SOME(n  :  nat  SUCH  THAT  n  IN  doealn(s)  ::  s[n]  -  x) 

MESSAGE  equal (si  s2  :  sequence {t}) 

REPLY  (b  :  boolean) 

WHERE  b  <->  ALL(n  :  nat  ::  Sl[n]  -  s2[n]) 


MESSAGE  Iess(s1  s2  :  sequence(t)) 

lexicographic  ordering  (dictionary  ordering  on  strings) 


WHEN  has_operatlon(t,  less)  &  partial  order lng( lessit) 

REPLY  (b  :  boolean) 

WHERE  ALL(s  :  sequence(t),  X  :  t  ::  []  <  [X,  $s]), 

ALL(s1  s2  :  sequence{t},  xl  x2  :  t 

::  [xl,  $S1J  <  [x2.  ts2]  <«>  xl  <  x2  |  xl  -  x2  &  si  <  S2) 

OTHERWISE 

REPLY  EXCEPTION  operation  not  applicable 


MESSAGE  subsequence(s1  s2  :  sequence(t)) 

REPLY  (b  :  boolean) 

True  if  the  eleeents  of  si  are  embedded  In  s2,  In  the  same  order. 


WHERE  ALL(s  :  sequence(t)  ::  subsequence([],  s)), 

ALL (si  s2  :  sequence(t),  x  :  t 
::  subsequence ([x,  Ssl],  s2) 

<«>  S0ME(s3  s4  :  sequence(t) 

::  s2  -  [$s3,  x,  $s4]  &  subsequence (s 1 ,  s4))) 

MESSAGE  Interval(x1  x2  :  t)  OPERATOR  .. 

WHEN  subtype(t,  total  order) 

REPLY  (s  :  sequence(t)) 

WHERE  sorted(less}(s)  &  ALL(x  :  t  ::  x  IN  s  <->  xl  <»  x  <-  x2) 
OTHERWISE 

REPLY  EXCEPTION  operatlon_not_appl I  cable 

MESSAGE  apply(f  :  FUNCTION,  si  :  sequence(t)) 

WHEN  doaaln(f)  •  [t] 

CHOOSE (rt  :  type  SUCH  THAT  rt  -  range(f)) 
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REPLY  (s2  :  sequence{rt}) 

WHERE  Iength(s2)  -  length(sl), 

ALL(n  :  nat  SUCH  THAT  n  IN  doaaln(sl)  s2[n]  -  f(s1[n])) 

OTHERWISE 

REPLY  EXCEPTION  type_error 

MESSAGE  reduce{f  :  FUNCTION} 

WHERE  doaaln(f)  ■  [t,  t]  &  range(f)  -  t 

&  SOME(X  :  t  : :  ALL(y  :  t  ::  f(y,  x)  -  y)) 

(s  :  sequence{t}) 

REPLY  (X  :  t) 

WHERE  IF  S  -  [] 

THEN  ALL(y  :  t  ::  f(y,  X)  -  y) 

ELSE  x  ■  f (sCI],  reduce(s[2  ..  length(s)],  f))  FI 

CONCEPT  sortedde  :  FUNCTION} 

WHERE  total_orderlng( le)(s  :  sequence(t)) 

VALUE  (b  :  boolean) 

WHERE  b 

<•>  ALL(n1  n2  :  nat  SUCH  THAT  1  <-  nl  <  n2  <-  length(s) 

::  le(s[nl],  s[n2])) 

CONCEPT  dlstlnct(s  :  sequence{t}) 

VALUE  (b  :  boolean) 

WHERE  b 

<«>  ALL(n1  n2  :  nat  SUCH  THAT  1  «-  M  <  n2  <«  length(s) 

: ;  s[n1]  "■  s[n2] ) 

CONCEPT  per«utatlon(sl  s2  :  sequenceft}) 

VALUE  (b  :  boolean) 

WHERE  b  <->  ALL(x  :  t  ::  frequency(x,  el)  -  frequencv(x,  s2)) 

CONCEPT  frequency(x  :  t,  s  :  sequence^}) 

VALUE  (n  :  nat) 

WHERE  n  -  NUMBER (k  :  nat  SUCH  THAT  s[k]  -  X  ::  k) 
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SAMPLE  INPUT  14 


MACHINE  air  I Ine  reservatlon_systea 

STATE ( f I :  aap{fllght  Jd,  flight),  res:  set{reservat Ion)) 

INVARIANT  ALL ( r :  reservation  ::  r  IN  res  ->  r.ld  IN  tl) 

INITIALLY  doaaln(f  I)  -  {  },  res  -  {  ) 

--  Interface  to  the  travel  agent 
MESSAGE  get_f  I  Ightjnfo 

(froa  to:  city,  earliest  departure  lastest  arrival:  tlae) 

REPLY(S:  set{f light}) 

WHERE  ALL(f :  flight 

: :  f  IN  s  <«>  f. origin  -  froa  &  f .destination  -  to  & 
f. departure  »«  earl lest_departure  &  f. arrival  <-  latestarrlval  ) 

MESSAGE  reserve(naae:  passenger.  Id:  fllghtjd,  day:  date) 

WHEN  Id  IN  fl  &  nuaber  res(id,  day,  res)  <  fl[ld). capacity  &  'has  res(name,  Id,  day,  res) 
REPLY(S:  set(seatjd})~ 

WHERE  ALL (s I :  seatjd  ::  si  IN  s  <«>  unass lgned(s I ,  Id,  day,  res)  ) 

TRANSITION  S0ME(r:  reservation 

SUCH  THAT  r.aho  -  naae  &  r.ld  «  Id  &  r.ithen  -  day  &  r.seat  «  I 
::  res  -  unlon(*res,  {r})) 

WHEN  Id  IN  fl  &  has_res(naae,  Id,  day) 

REPLY  EXCEPTION  previous  reservation 
WHEN  '(Id  IN  fl) 

REPLY  EXCEPTION  Invalid  flight  Id 
OTHERWISE  REPLY  EXCEPTION  no_SMtS_ava  I  lab  I  © 

MESSAGE  cancel_reservation( Id:  fllghtjd,  day:  date,  naae:  passenger) 

WHEN  Id  IN  fl  &  has_res(naae.  Id,  day,  res) 

REPLY(conf Iraatlon:  string) 

WHERE  conf Iraatlon  -  "reservation  cancelled" 

TRANSITION  res  •  *res  -  {find  re s(ld,  day,  naae,  res)} 

WHEN  '(id  IN  fl) 

REPLY  EXCEPTION  Inva I  Id  f  I  Ight  Id 
OTHERWISE  REPLY  EXCEPTION  no_such  jeservat Ion 

MESSAGE  asslgn_seat 

(Id:  fllghtjd,  day:  date,  naae:  passenger,  seat:  seatjd) 

WHEN  hasjes(naao.  Id,  day,  res)  &  unasslgned(seat.  Id,  day,  res) 

REPLY(conf iraatlon:  string) 

TRANSITION  find  res(ld,  day,  naae,  res). seat  -  seat 

WHEN  has  res(naae.  Id,  day,  res)  &  'unasslgned(seat.  Id,  day,  res) 

REPLY  EXCEPTION  seat  not  available 
OTHERWISE  REPLY  EXCEPTION  no_such  jeservat  Ion 

—  Interface  to  the  alrl  Ine  aanager 

MESSAGE  update  pricedd:  flight  Id,  price:  aoney) 

WHEN  Id  IN  fl  ~ 

REPLY (conf Iraatlon:  string) 

TRANSITION  fl[ld]. price  -  price 


OTHERWISE  REPLY  EXCEPTION  no_such_f I ight 


MESSAGE  add_f  I  lght( Id:  fllghtjd,  origin  destination:  airport, 

departure  arrival:  time,  capacity:  integer,  price:  money) 

WHEN  '(Id  IN  fl) 

R£PLY(conf Iraatlon:  string) 

WHERE  confirmation  -  “flight  added" 

TRANSITION  fl[ld]  -  createtf I ight ( id,  origin,  destination,  departure, 

arrival,  capacity,  price) 

OTHERWISE  REPLY  EXCEPTION  f I Ight _already  exists 

MESSAGE  drop  flighted:  flight  Id) 

WHEN  Id  IN  fl 

REPLY(conf  I  nation:  string) 

WHERE  confirmation  -  ‘flight  dropped' 

TRANSITION  fl[ld]  -  I 

OTHERWISE  REPLY  EXCEPTION  nosuch J I Ight 

—  concepts 

CONCEPT  number  res( Id:  flight  Id,  d:  date,  rs:  set(reservatlon)) 

VALUE (n :  Integer) 

--  the  number  of  reservations  held  for  flight  Id  on  day  d 
WHERE  SOME(S:  set{reservat Ion)  SUCH  THAT 

ALL(r :  reservation  ::  r  IN  s  <-»  r  IN  rs  &  r.when  »  day  &  r. flight  -  id  ) 
::  n  -  slze(s)  ) 


CONCEPT  has  res(name:  passenger,  Id:  flight  Id,  day:  date,  rs:  set{reservatlon}) 
VALUE (b:  boolean) 

—  true  If  the  passenger  holds  a  reservation  on  day  for  flight  Id 
WHERE  b  <->  SOME ( r :  reservation 

SUCH  THAT  r.who  -  name  &  r. flight  •  Id  &  r.when  -  day 
::  r  IN  rs  ) 

CONCEPT  unasslgned(sl :  seatjd,  id:  fllghtjd,  day:  date,  rs:  set{reservat  Ion}) 
VALUE(b:  boolean) 

--  true  If  no  one  holds  a  reservation  for  seat  si  on  day  for  Id 
WHERE  b  <->  ALL(r :  reservation 

SUCH  THAT  r.seat  ■  si  &  r. flight  »  Id  &  r.nhen  -  day 
::  -(r  IN  rs)  ) 

CONCEPT  reservation:  type 

WHERE  reservation  -  tuplefwho  ::  passenger,  when  ::  date,  id  ::  fllghtjd, 

seat  ::  seat  Id  } 

CONCEPT  city:  type 

CONCEPT  fllghtjd:  type  WHERE  fllghtjd  -  string 

CONCEPT  passenger:  type  WHERE  passenger  •  string 

CONCEPT  date:  type  CONCEPT  seatjd:  ty^e  WHERE  seatjd  -  string 

CONCEPT  money:  type  CONCEPT  airport:  type  WHERE  airport  ■  string 

END  TYPE  flight  M00EL(?)  INVARIANT  ?  END 

TYPE  time  INHERIT  total  order  M0DEL(?)  INVARIANT  ?  END 


! 
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SAMPLE  OUTPUT  14 


MACH  I NE  aim  ne_reser  vat  1  on_syste« 

STATE  (fl  :  aapCf I lght_ Id,  flight},  res  :  set{reservatlon}) 

INVARIANT  ALL(r  :  reservation  ::  r  IN  res  «>  r.ld  IN  fl) 

INITIALLY  doaaln(fl)  -  {},  res  »  {}  --  Interface  to  the  travel  agent 


MESSAGE  get_f I lght_lnfo(froa  to  :  city,  earl  lest  departure  lastest  arrlval 

:  tlae) 

REPLY  (s  :  set{f light}) 

WHERE  ALL ( f  :  flight 
::  f  IN  s 

<->  f. origin  -  froa  &  f .destination  -  to 
&  f. departure  >«  earl lest_departure 
&  f. arrival  «-  latest_arrlval) 

MESSAGE  reserve(naae  :  passenger,  Id  :  fllghtld,  day  :  date) 

WHEN  Id  IN  fl  &  nuaber_res(id,  day,  res)  <  f I [ Id] . capacity 
&  'has  res(naae,  Td,  day,  res) 

REPLY  (s':  set{seat_id}) 

WHERE  ALL(s I  :  seat_ld  ::  si  IN  s  <■>  unasslgned(sl ,  Id,  day,  res)) 
TRANSITION  SOME(r  :  reservation 

SUCH  THAT  r.who  -  naae  &  r.ld  -  id  &  r.when  -  day 
&  r.seat  -  I  ::  res  -  unlon(*res,  {r})) 

WHEN  Id  IN  f I  &  has_res(na*a,  Id,  day) 

REPLY  EXCEPTION  previous  reservation 
WHEN  "(Id  IN  fl) 

REPLY  EXCEPTION  invalid  flight  Id 
OTHERWISE 

REPLY  EXCEPTION  no_seats_ava I  table 

MESSAGE  cancel  reservatlon( Id  :  flight  Id,  day  :  date,  naae  :  passenger) 
WHEN  id  IN  fl  &  has_res(naae,  Id,  day,  res) 

REPLY  (conf IraatTon  :  string) 

WHERE  conflraatlon  -  "reservation  cancelled" 

TRANSITION  res  -  *res  -  (find  res(ld,  day,  naae,  res)} 

WHEN  '(Id  IN  fl) 

REPLY  EXCEPTION  Inval Id  f I Ight  Id 
OTHERWISE 

REPLY  EXCEPTION  no_such_reservatlon 

MESSAGE  asslgn_seat(ld  :  flightjd,  day  :  date,  naae  :  passenger,  seat 
:  seatjd) 

WHEN  has_res(naae,  Id,  day,  res)  &  unasslgned(seat.  Id,  day,  res) 

REPLY  (conflraatlon  :  string) 

TRANSITION  f!nd_res(id,  day,  naae,  res). seat  -  seat 
WHEN  has_res(naae,  Id,  day,  res)  &  'unassigned(seat,  Id,  day,  res) 

REPLY  EXCEPTION  seat_not_aval table 
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OTHERWISE 

REPLY  EXCEPTION  no_such_reservat ion 
Interface  to  the  air  I lne_«anager 


MESSAGE  update  pr ice( Id  :  flight  Id,  price  :  eoney) 

WHEN  Id  IN  f I 

REPLY  (conf treat  Ion  :  string) 

TRANSITION  fl[ld]. price  »  price 
OTHERWISE 

REPLY  EXCEPTION  no_such_f I Ight 

MESSAGE  add_f I lght(ld  :  fiight_ld,  origin  destination  :  airport,  departure 
arrival  :  tlee,  capacity  :  Integer,  price  :  eoney) 

WHEN  '(Id  IN  fl) 

REPLY  (conf Ireatlon  :  string) 

WHERE  conf treat  Ion  «  "flight  added* 

TRANSITION  fl[ld] 

-  createef I lght(ld,  origin,  destination,  departure,  arrival, 
capacity,  price) 

OTHERWISE 

REPLY  EXCEPTION  f I ight_a I ready_exists 

MESSAGE  drop  f  I  iflht( Id  :  flight  Id) 

WHEN  Id  IN  f  I 

REPLY  (conf Ireatlon  :  string) 

WHERE  conf treat  Ion  -  'flight  dropped" 

TRANSITION  fl[id]  -  I 
OTHERWISE 

REPLY  EXCEPTION  nosuch  f I Ight  —  concepts 


CONCEPT  nueber_res( id  :  fllghtjd,  d  :  date,  rs  :  set(reservat ion)) 

VALUE  (n  :  Integer) 

the  nueber  of  reservations  held  for  flight  id  on  day  d 

WHERE  SOME(s  :  setfreservat Ion) 

SUCH  THAT  ALL(r  :  reservation 
::  r  IN  s 

<->  r  IN  rs  &  r.when  •  day  &  r. flight  -  id) 

::  n  -  slze(s)) 

CONCEPT  has_re$(naee  :  passenger.  Id  :  fllghtjd,  day  :  date,  rs 
:  setfreservation}) 

VALUE  (b  :  boolean) 

true  If  the  passenger  holds  a  reservation  on  day  for  flight  id 
WHERE  b 

<->  S0ME(r  :  reservation 

SUCH  THAT  r.who  -  naee  &  r.fllght  ■  Id  &  r.when  »  day 
::  r  IN  rs) 
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CONCEPT  unasslgned(sl  :  seat_ld,  id  :  fllghtjd,  day  :  date,  rs 
:  set{r8servation}) 

VALUE  (b  :  boolean) 

—  true  If  no  one  holds  a  reservation  for  seat  si  on  day  for  id 
WHERE  b 

<->  AlL(r  reservation 

SUCH  THAT  r.seat  -  si  &  r. flight  -  Id  &  r.when  -  day 
::  "(r  IN  rs)) 

CONCEPT  reservation:  type 
WHERE  reservation 

-  tuplefwho  ::  passenger,  when  ::  date,  Id  ::  flight  Id,  seat 
seat_td} 

CONCEPT  city:  type 

CONCEPT  flight  Id:  type 
WHERE  fllghtjd  -  string 

CONCEPT  passenger:  type 
WHERE  passenger  -  string 

CONCEPT  date:  type 

CONCEPT  seat  Id:  type 
WHERE  seatjd  -  string 

CONCEPT  soney:  type 

CONCEPT  airport:  type 
WHERE  airport  *  string 
END 

TYPE  flight 

MODEL  (?) 

INVARIANT  ? 

END 

TYPE  ti*e 

INHERIT  tota (order 

MODEL  (?) 

INVARIANT  ? 

END 
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